krypted.com

Tiny Deathstars of Foulness

On Sunday, I mentioned making your forward and reverse DNS entries match up. But I didn’t really discuss what to do if they don’t. For those readers moving into Ubuntu from Mac OS X Server, you’ll note that at installation time, if the hostname doesn’t match the A record and PTR for your server then it will install DNS and make them match up. The reason for this is that host names are a critical aspect in how many of the network services that modern services run. If you don’t have DNS or if you want to fire up DNS in the same manner that Mac OS X Server does it then let’s look at doing so here. First up, let’s get the packages that we’ll need installed using apt-get, which includes bind9 and dnsutils:
apt-get install bind9 dnsutils
Once those are installed, let’s define our zone and reverse zone in /etc/bind/named.conf.local:
zone “krypted.com” { type master; file “/etc/bind/zones/krypted.com.db”; }; zone “210.168.192.in-addr.arpa” { type master; file “/etc/bind/zones/rev.210.168.192.in-addr.arpa”; };
Note: If you’re cut/copy/pasting here, the double-quotes are going to need to get replaced with unformatted ones. If you have other forward or reverse zones then you will need to add them using the same format as above. Once you’re done, save the file. Next, let’s tell the server where to look when attempting to resolve names that it does not host. This information is stored in the options array in /etc/bind/named.conf.options. This is currently commented out (commented lines start with //) so let’s uncomment the forwarders section (by removing the // in front of the lines) and change the IP of that forwarder from 0.0.0.0 to the IP address of your server. It should look similar to the following when complete:
forwarders { 4.2.2.2 };
Next, we’re going to create our
mkdir /etc/bind/zones touch /etc/bind/zones/krypted.com.db touch /etc/bind/zones/rev.210.168.192.in-addr.arpa
Now that we’ve created our files, let’s edit them. First, open /etc/bind/zones/krypted.com.db and look for all instances of krypted.com, replacing them with the domain name that you would like to use. Also, look for all of the records and make sure that they match with the name and IP that you would like to use, creating new lines for each new record:
krypted.com. IN SOA ns1.krypted.com. admin.krypted.com. ( 2007031001 28800 3600 604800 38400 ) krypted.com. IN NS ubuntu08.krypted.com. krypted.com. IN MX 10 mail.krypted.com. www IN A 192.168.210.2 home IN A 192.168.210.2 mta IN A 192.168.210.2 ubuntu08 IN A 192.168.210.254
Next, we’ll populate the reverse zone file. You’ll need to replace my instances with your own as in the previous section. Open /etc/bind/zones/rev.0.168.192.in-addr.arpa in your favorite text editor and edit away:
@ IN SOA ubuntu08.krypted.com. admin.krypted.com. ( 2007031001; 28800; 604800; 604800; 86400 ) IN NS ubuntu08.krypted.com.
1 IN PTR krypted.com
Next, we’ll restart the DNS services to accept these massive changes we’ve made:
/etc/init.d/bind9 restart
Next, edit the /etc/resolv.conf file to set the DNS server and (optional) search domain. Then change it to look something like the following:
search krypted.com nameserver 192.168.210.254
Finally, you can use dig and nslookup to test the lookups and make sure they work. For example:
nslookup ubuntu08.krypted.com

November 22nd, 2010

Posted In: Ubuntu, Unix

Tags: , , , , , , , , , ,

Previously we looked at installing Git on Mac OS X. Now let’s take a look at using it. The first step is to add a new local git repository that looks to a remote repository. In the following example I’m going to add a local repository called custom-safari based on the git repository at packages/custom-safari on git.krypted.com.
git remote add custom-safari git://krypted.com/packages/custom-safari.git
Next make sure you’re using the latest from the repository:
git pull
Then checkout from the master git branch:
git checkout -b custom-safari/master
Now pull the files you’ve checked out:
git pull custom-safari master
Now you can do your work. Edit the files, wok on them and when you’re done we’ll look at putting them back in the repository. Before all commits, make sure to know which files are the most recent:
git status
Commit your changes:
git commit -a
Finally, push your changes back to your master:
git push
Once you’ve started working with git you may find that you would like to customize a few of the settings to make life a little easier. For these, check out the alias.st, alias.ci, alisas.co and alias.br, which can be really helpful. Add colors:
git config –global color.ui auto
If you screw up and want to reset your local repository:
git checkout -f
Figure out what changed:
git diff

November 22nd, 2009

Posted In: Mac OS X, Mac OS X Server, Mac Security, Ubuntu, Unix

Tags: , , , , , ,

You have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas. However, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1. Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services. You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd. The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.

September 28th, 2009

Posted In: Mac OS X Server, Unix

Tags: , , , , ,

Once you have been using DeployStudio for a time, you’ll invariably end up creating a new master image.  This is a hot topic this summer, given that Apple will be releasing Mac OS X 10.6 later this year and many people integrating DeployStudio want to make sure that they can manage the solution themselves during the subsequent updates.  Provided you have been leveraging all of the best in package based imaging this might be a relatively small file, or if you are using a monolithic image for distribution it might be a fairly large file.  Either way, DeployStudio makes it fairly straight forward to create a new master image.  To do so, first get your imaging station ready using similar techniques to how you have created your master images (known in DeployStudio as Masters) in the past.  Then follow these straight forward instructions:
Creating a Master Image from an Imaging Station Using DeployStudio

Creating a Master Image from an Imaging Station Using DeployStudio

August 7th, 2009

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , , , , , , ,