We Launch Startups.

Apt is a wonderful tool, but it does have its quirks. One of those is that it likes to ask you interactive questions during package installation. This makes total sense when a human is doing apt-get install foobar, but it causes all sorts of consternation when you want to automatically install packages. (You do this all the time with Puppet, which I’ll talk more about at the end of this post.)

The answer to this problem is to pre-seed debconf with the correct answers to it’s questions. To do this, first you need to install the package by hand:

$ apt-get install libnss-ldap

You’ll need to provide answers to the questions it asks, which we’re going to re-use later as the basis for our seed file. Next, make sure you have debconf-utils installed, and grab the answers to your questions:

When using runit with Upstart in Ubuntu 7.04, you’re going to run in to a couple of problems. The first is that the package doesn’t install cleanly without the presence of /etc/inittab, which Upstart doesn’t need. You can fix that with a simple:

$ sudo touch /etc/inittab

Now, you need to actually add runit to Upstart. You do this by putting the following in /etc/event.d/runsvdir:

Assuming you only have Windows 2003 domain controllers, go ahead and set it at Windows 2003. It needs to be at least Windows 2000 Native.

Step 0. Create a more useful MMC Snap In.

The default snap-in’s for Windows make things difficult for handling Group Policy, since you so often need to move back and forth between the group policy itself and Active Directory. So our first step is to create a consolidated MMC view, so we can do both in one window.

Start -> Run -> mmc

File -> Add/Remove Snap-in

Click “Add”

Select “Active Directory Users and Computers”, click “Add”

Select “Group Poloci Management”, click “Add”

Click “Close”, then click “OK”

Expand the “Console Root” mini-window.

Select “File” -> “Save”, Click your Desktop, and call it GPMCAD

Now, any time you want to play with Group Policy, you can just double click the GPMCAD.msc on your desktop.

Step 1. Create the Computer OUs

Each class of machine (“Webserver”, “Database”) needs to have it’s own OU, which we will use for setting the proper Group Policy.

Expand “Active Directory Users and Computers”

Expand your Forest, and Navigate to the place you want to create new computer OUs. (“sea/computers” in our example)

Create a new OU for a class of machines. Right click on the parent container, select “New”, then “Organizational Unit”. Give it a name (“Webservers”,) then click “OK”.

Now, right click on the computers you want to have populate this OU, and select “Move”. Navigate to the new OU, and click “OK”.

Step 2. Create the User Groups

For each class of machine, we’ll create two groups: one for Administrators, and one for regular Users.

Go to the OU where you want the groups located (“sea/groups” in our example.)

Right click on the OU, select “New”, then “Group”

In group name, put “Webserver Users”. (Where “Webservers” is our example group name; yours should match whatever the Computer OU you created before was.)

Under “Group Scope”, select “Universal”, and click “OK”

Right click on your new group, and select “Properties”

Click the “Members” tab, click “Add”, and type in the users you want to have non-administrator access to this host. When you’re done, click “OK”. (How to use this dialog is beyond the scope of this document, I think. ;)

Once you have all the users, click “OK”.

Now, repeat these steps, but call the group “Webserver Admins”, and ensure you only populate it with the users who should have Administrator privileges on this host.

Step 3. Create the new Group Policy

Now that we have our systems in a new OU, and our Authentication groups created, we need to create the group policy to apply our settings.

In the MMC, open “Group Policy Management” -> “Forest: yourdom.com” -> Domains -> “yourdom.com”. This will reflect the root of the Active Directory tree we were working with in Step 2.

Navigate to the Computer OU we created, right click, and select “Create and Link a GPO Here…”

Give it a name like “Webserver Permissions”.

Expand the OU we just right clicked on, exposing your new GPO. Right click on it, and select “Edit”.

Step 4. Edit the new Group Policy.

You should have just popped up the “Group Policy Object Editor.” First, lets set some limits on who can log in via the Console and Terminal Services.

Click the “Add…” button next to “This group is a member of:”, and type “Administrators”. Click “OK”

Click “OK” to close the dialog.

Now, repeat the above, but for the “Webserver Users” group. When the time comes to set what group it should be a member of, make it “Remote Desktop Users”.

Close the Group Policy Object Editor dialog.

Step 5. Refresh the Group Policy on the clients, and test.

Depending on how often your Group Policy refreshes, you may have to wait a while. You can force the issue by running gpupdate /FORCE on the computers you want to update. Do that now, so we can make sure everything is working.

Now, try terminal serving as a User who is a member of the “Webserver Users” group. You should have access, but not Administrative privileges.

Next, try and log in as a member of the “Webserver Admins” group. You should have full administrative rights to the host.

Now it’s a Domain Administrators turn. Again, they should have full Administrative access.

Finally, try and log in as a user who isn’t in any of the above groups. You should get the “To log on to this remote computer..” speech.

Step 6. Rinse and Repeat.

For each class of systems you want to manage, repeat the above process. When you are done, you should have a super easy to manage domain structure, and getting the access privileges right for new hosts is as easy as moving them to the right place in Active Directory.