NCSU OIT Integration Services

Well, I'm finally getting some of my promises kept.  The live account management scripts, hot off scripts02 can be found at

https://svn.unity.ncsu.edu/svn/shs-general/acctmgmt/trunk

Both Wade and Joe have mentioned that subversion isn't working for them -- I'm still checking on that. :-) 

Folks,

Since effective today OIT has a new logo, I've poked it onto this site to show our solidarity.

So folks had trouble accessing \\unity.ad.ncsu.edu\dfs this morning.  In checking to see if things were set up according to http://integrate.oit.ncsu.edu/node/81, I noticed that fs03 was no longer a dfs namespace server, and that on fs00 the "execute" permission had been removed.  I poked both issues, restarted the DFS service on fs00 and we seem to be back on the air.

Folks,

 I've removed the trust between unity.ad.ncsu.edu and the test domain test3.unity.ad.ncsu.edu .

We still have a parent-child trust with test2.unity.ad.ncsu.edu that's proving troublesome to remove.  I think the issue is that we don't have all the proper SRV records in QIP and so dcpromo can't find something it thinks it needs.

Joe J and I have added most of the servers that he manages certificates for to the monitoring tool at: 

https://sysnews.ncsu.edu/tools-bin/sslkey-status

This is NOT nagios, but a seperate app that will send an e-mail starting 60 days from when a cert expires.   The whole team can add, remove and manage the host lists.

There were several hosts that we couldn't reach from the sysnews servers to monitor them. including:

Muhahaha.  Out evil plans take a step forward with the creation of a Subversion Repository.

 The URL is https://svn.unity.ncsu.edu/svn/shs-general/

It's private, so you must log in with your Unity ID, and be one of the cool shs-general kids.

Partly as a spinoff from last Friday's meeting, and partly from my own reflections on stuff I've done that hasn't worked, I've been wrestling with a question. The question I have is, how do we meet management needs without needless bureaucracy? How can we meet these needs in a sensible, sustainable way?

Roughly, from my experience, management needs:

So, I'm working on getting Jonn access to all the unix-y things he may need. Along the way, I learned a tidbit worth remembering.

We have a Hesiod (old unix-y service) slash LDAP (new unix-y service, see http://ldap.ncsu.edu) group named "microsys, that is used to grant permissions for things. Things like AFS permissions and access to subversion.

It's managed here:

https://sysnews.ncsu.edu/tools-bin/hesiod-groups

Putting togather a spread sheet of the common task that are done with AD and the permissions that are required for them. I attached the "rough" rough draft to get comments from everyone.

 -Jonn

OK, so these may be the worst meeting notes ever recorded, as I didn't write anything down and am just trying to do something productive while I wait for sysprep to finish.

We had an informal get together to talk about what we're concerned about/working on and to continue to introduce Jonn into our little group.

We talked a lot about needed to document our security policies regarding who would be a domain/enterprise admin.  We're in a bad place, in that we can't identify why some of the domain/enterprise admins have that level of access.