Configuring Alerts in Mavericks Server

Mavericks Server comes with a few new alerting options previously unavailable in versions of OS X. The alerts are sent to administrators via servermgrd and configured in the Server app (Server 3). To configure alerts in Mavericks Server, open the Server app and then click on Alerts in the Server app sidebar. Next, click on the Delivery tab. Screen Shot 2013-10-04 at 8.30.47 PM At the Delivery screen, click on the Edit button for Email Addresses and enter every email address that should receive alerts sent from the server. Then click on the Edit button for Push Notifications. Here, check the box for each administrator of the server. The email address on file for the user then receives push notifications of events from the server. Screen Shot 2013-10-04 at 8.29.40 PM
Click on OK when you’ve configured all of the appropriate administrators for alerting. Click on the Edit… button for Push and if Push notifications are not already enabled you will run through the Push Notification configuration wizard. Screen Shot 2013-10-04 at 8.40.33 PM Then, check the boxes for Email and Push for each of the alerts you want to receive (you don’t have to check both for each entry). Alerts have changed in OS X Server, they are no longer based on the SMART status of drives or capacity; instead Delivery is now based on service settings.
Finally, as with previous versions of OS X Server, Mavericks Server has snmp built in. The configuration file for which is located in the /private/etc/snmp/snmpd.conf and the built-in LaunchDaemon is, where the actual binary being called is /usr/sbin/snmpd (and by default it’s called with a -f option). Once started, the default community name should be COMMUNITY (easily changed in the conf file) and to test, use the following command from a client (the client is in the following example): snmpwalk -On -v 1 -c COMMUNITY

10 Features I Miss From Mountain Lion & Mountain Lion Server

Apple’s not going to slow down innovation just to make me happy. I get that. But what have I noticed most about the differences between Mountain Lion and Mountain Lion Server and their predecessors, and maybe what to do to get some of them back?
  1. Podcast Producer: I am going to just put it out there. I liked Podcast Producer. I hope it shows back up in the future, even though I’m controlling my expectations. As someone who deals with a lot of video, there are a number of features that were really helpful to me, with or without Xgrid. I’ve replaced the command line aspects with tools such as ffmpeg, which we used in addition to at times, but some of the ways that pcastaction did things were really elegant comparably. On the graphical side, much of the functionality is available in the various sites that produce video streams and of course, there’s always YouTube. Either way, in regards to Mountain Lion Server, this represents one of the most substantial changes for those of us that deal with video.
  2. DHCP: I know, I know… I wrote an article on how to keep using DHCP. That doesn’t mean that the lack of GUI options is any less irritating. Every time I manually edit a config file that should have a GUI front-end it makes me ornery. Not that I’m not always ornery, but that’s not the point here…
  3. RSS: This is more of a client thing. But and Safari used to give me the ability to quickly and easily look at RSS feeds and handled them in a way that was very streamlined with my experience across the rest of the operating system. I am now using more and more Google Reader along with tools like Reeder, but I liked the fact that everything I needed for RSS madness was installed on even the test systems I used
  4. X11: I know, I know… Use XQuartz. It was nice having it built in though…
  5. Web Sharing: I guess the answer here is to just buy OS X Server. You can still fire up the LaunchDaemon and use Apache, but it’s a bit of a challenge. And the version in Server isn’t identical to Apache in Mountain Lion. There are two ways I’ve handled this. The first is to install Mountain Lion Server and then use the command `webpromotion demote` to switch the Apache configuration back to that of a client computer. The second is to fire up the LaunchDaemon directly using launchctl. If you’d like, there are also a number of free and/or 3rd party web servers, such as MAMP.
  6. Negative Mode: Well, I covered this already, and while the keystroke was gone, the feature never was – but here’s how to fix. Also, @sacrilicious turned me on to nocturne, which is pretty cool as well!
  7. iCal, Address Book and NetBoot: Actually, they’re now called Calendar, Contacts and NetInstall respectively. But still there. I actually like the renaming a lot, so I guess I don’t really miss any of them.
  8. Radius: OK, it’s there. Just command line only (unless you’re using an Apple AirPort). Maybe I should write an article about radius…
  9. The Server command line options: Actually, they just moved to a relative path to /Applications/, as I mentioned here.
  10. Server Admin: I was going to say FTP, then I remembered it’s back. And then I remembered I never missed it in the first place. But dropping the remainder of the GUI tools for servers represents a bit of a challenge, mostly in figuring out how to do a few of the minor things, like enabling Server Side File Tracking, etc.

MacTech InDepth In New York

I have been added as a speaker at MacTech InDepth in New York. If you haven’t signed up yet, and you work with Mac OS X Server then you should really check out the sessions that have been planned:
  • The Elephant in the Room: The New Lion OS X is out, now what? There are a lot of differences to contend with between Lion and Snow Leopard. Now with the new Mountain Lion update, what changes can we expect to see? We discuss the differences in advanced services, GUI simplicity, and Apache management GUI’s. We help you understand the updates in the new OS and make the transition easier. We go over the new updates of Lion over the Snow Leopard server.
  • Setting solid foundations: To truly grasp the power of Lion, you need to set up solid foundations. We go over minimum requirements for internet DNS, and tackle router tricks. We discuss open directory and what it was used for.
  • Mobile Device Management 101: Apple’s IPCU/Apple Configurator: Mobile Device Management is vital to businesses, large or small. We have an extensive overview of profile manager and how you can use mobile device management on OS X. For those still using Snow Leopard, we go over your options and discuss the possibility of using third parties as a solution.
  • DNS, Ahh, run away, run away: In this session, we tackle DNS and break it down and show how simple it is to work with. We go over how DNS works and cover different components such as internet DNS and internal DNS.
  • Administering a Server with just We show you how to use and control administrative programs. For the services, we go over Address Book, iCal, iChat, and Mail.
  • Web Administration of OS X Server : Web Admin on Lion Server versus Snow Leopard is covered, dealing with the differences and how to use each system effectively. On Lion server, we cover using FTP without a GUI.
  • Going old school, using the old tools: After getting used to Snow Leopard we go over the major differences between Snow and Lion and how you can handle the transition. We go over server admin and what is still left in the program and why it has been left.
  • Deployment Part I: Tools & Concepts: In tools and concepts we learn that there aren’t stark differences between Lion server and Snow Leopard. NetBoot, NetRestore and third party tools are covered; we talk about how NetBoot works and what the differences between NetBoot and NetRestore are. Along with this we cover Network configuration requirements and using software update server.
  • Deployment Part II: DeployStudio: DeployStudio is covered in-depth; we cover creation techniques and management techniques.
Overall, this represents a nice, fast way to update your skills to allow for managing Lion Server and to get up to speed with those new to the platform. One thing I like about the session list is that it goes beyond the stock server implementation and looks at DeployStudio, MDM and other important topics not purely server oriented. I hope to see you all there!
These vagabond shoes, are longing to stray Right through the very heart of it – New York, New York

Working with Postgres from the Command Line in Lion Server

Mac OS X Server 10.7, Lion Server, comes with a few substantial back-end changes. One of these is the move from SQLite3 to PostgreSQL for many of the back-end databases, including Wiki and Podcast Producer (collab), Webmail (roundcubemail), iCal Server and Address Book Server (caldav) and as the back-end to the newest service in Lion Server, Profile Manager (device_management). As such, it’s now important to be able to use PostgreSQL the way we once used SQLite3, when trying to augment the data that these databases contains, as there currently aren’t a lot of options for editing this data (aside from manually of course). Postgres has a number of commands that can be used to interact with databases. The most important is probably psql. Many of the other commands simply provide automated options to psql, and over time I’ve started using psql for most everything. For example, PostgreSQL comes with a command /user/bin/createuser. However, as it’s usually more verbose with errors, I like to use psql to do this. In Lion Server, the only user that can access the Postgres databases is _postgres, installed by default with Lion Server. Because a lot of commands require passwords and we might not always want to provide write access to the databases, we’re going to create a new SuperUser, called krypted with a password of daneel. To do so, we will have to use the _postgres user to invoke psql. Any time you want to invoke psql with a different user than the user you are currently logged in as, use the -U option. To define a database, use the -d option (device_management providing access to Profile Manager data, caldav to iCal Server data roundcubemail to WebMail data and collar to Wiki data). To string this together, for accessing the device_management database as _postgres: psql -U _postgres -d device_management To then create a new user called krypted with a password of daneel we’ll use the create option, defining a user as the type of object to create, followed by the user name and then with password followed by the password (single quoted) and then createuser; as follows: device_management=# create user krypted with password 'daneel' create user; Now that there’s a valid user, let’s see what else we can do. To see all of the tables, use d: device_management=# d As you can tell, there are a bunch of them. Run the help command to see a list of SQL commands that can be run and ? for a list of psql options. To put some SQL commands into action, we’re going to look at the tasks that have been performed by Profile Manager. These are stored in the tasks table (aptly named), so we’re going to run the following SQL query (note a space followed by a semi-colon is required at the end of this thing): device_management=# select * from "public"."tasks" limit 1000 offset 0 ; Or to make it a bit simpler if you don’t have a lot of data in there yet: device_management=# select * from "public"."tasks" ; After seeing the output, you’ll probably be a little appreciative of Apple’s formatting. Next, let’s look at dumping the databases. We’re going to create a folder on the root of the volume called db_backups first: sudo mkdir /db_backups This is where these backups will end up getting stored. We’ll continue using the _postgres user for now. To do our database dumps, we’re going to use pg_dump, located at /usr/bin. First, we’ll dump the device_management database (but first we’ll stop the service and after we’ll start it – all commands from here on out also assume you’re sudo’d): serveradmin stop devicemgr pg_dump -U _postgres device_management -c -f /db_backups/device_management.sql serveradmin start devicemgr And the other 3 (stopping and starting each in the process): serveradmin stop web pg_dump -U _postgres roundcubemail -c -f /db_backups/roundcubemail.sql serveradmin start web serveradmin stop wiki pg_dump -U _postgres collab -c -f /db_backups/collab.sql serveradmin start wiki serveradmin stop addressbook serveradmin stop calendar pg_dump -U _postgres caldav -c -f /db_backups/caldav.sql serveradmin start addressbook serveradmin start calendar I haven’t had any problems running the dumps with the services running, but it’s better safe than sorry I guess. I’d probably also add some logging and maybe dump the output of full status for each service to try and track if all is well with each. Any time a service didn’t fire back up I’d then build in a sanity check for that event. There’s also a database for postgres itself, so let’s back that up as well since we’re here: pg_dump -U _postgres postgres -c -f /db_backups/postgres.sql These can then be restored using psql with the -d option to define the database being restored into and the -f option to define the file being restored from. For example, to restore collab: psql -U _postgres -d collab -f /db_backups/collab The databases are all dumped daily using pg_dumpall. These are stored in /var/pgsql but can be changed using serveradmin settings (for example, to move them to /var/pgsql1): serveradmin settings postgres:dataDir = "/var/pgsql1" If you mess up the Profile Manager database (before you put any real data into it) you can always use the /usr/share/devicemgr/backend/ script to trash the database and start anew (although I’d just use a snapshot of a VM for all this and restore from that). You can also connect to Postgres remotely, or locally through a network socket (common in Apache uses) by adding a listener. To do so, we’ll need to restart the Postgres LaunchDaemon. First, back up the file, just in case: cp org.postgresql.postgres.plist org.postgresql.postgres.plist.OLD_CSE Then stop postgres: serveradmin stop postgres Then edit the org.postgresql.postgres.plist file to change the following line: listen_addresses= To read: listen_addresses= Then fire up postgres again: serveradmin start postgres And now let’s scan port 5432 (the default TCP and UDP port used for postgres) for localhost: /Applications/Utilities/Network 5432 5432 We could have used another IP address for the listen_addresses as well, but with that _postgres user not requiring a password it didn’t really seem prudent to do so. Once you’ve enabled a socket, you’ll then be able to use one of the many GUI tools to manage postgres. Navicat is available on the Mac App Store for $5 and PGnJ is a nice, easy to use, free one. There are tons of others, but I don’t spend a lot of time in a SQL GUI and so don’t need more than a cheap app will get me. One nice thing about most of these is that they help you to form SQL queries (or they help me). This can get really nice if you are, for example, trying to get some good reporting on Profile Manager (a feature it’s a bit light on right now). Finally, don’t do any of this stuff on a production box, except maybe if you want more than nightly backups unless you think pretty hard about what you’re doing and know the exact impact of doing something. If you were to edit the databases on a live boxen, then you can safely assume that with how all of the objects in those databases use GUIDs that you’re probably going to break something, if not bring the whole house of cards tumbling down.

Spots Available in Collaboration Services MacWorld Session

There are still some openings in the session I’ll be doing on February 10th at MacWorld on Collaboration Services. It’s going to be about shared wikis, blogs, calendars, address books and a little Podcast Producer in the end. If you are thinking of deploying this type of solution or have deployed them but would like to know more then check it out:

Address Book File Locations

Address stores its preferences in the following property list files in ~/Library/Preferences:
The Address Book data itself is stored in ~/Library/Application Support/AddressBook, Here you will find:
  • The SQL Lite database (*.abcddb).
  • Any images associated with addresses are located in the Images folder in that directory
  • Any contacts synchronized (ie – from Address Book services of Mac OS X Server to the local computer are synchronized into the Sources directory (into the .abcddb file located there)
  • Any metadata associated with the contacts in the Metadata directory
  • The MailRecents-v4 file, which contains a cache of the most recently used email addresses
  • A Configuration.plist property list that has the settings for that specific database.
You can interact with the Address Books programatically using sqlite3, which I covered a little while back. You can also interact with it from the API layer.

Snow Leopard &

If you grew accustomed to using in Leopard and you’re thinking about an upgrade to Snow Leopard then you might want to pause, if only for a moment. You see, there is no in Snow Leopard. If you were using to allow users to create Blogs and Wikis, then check out the new web interface and see if the specific functionality you seek is there; otherwise look into SACLs and consider pushing out Workgroup Manager. If you were using it to hook into LDAP and allow for looking up contact information then check out Address Book Server, included in 10.6 Server…

sqlite3 and Address from the Command Line

The Mac OS X program, Address Book uses sqlite3 to store information.  The actual database is located in each users Library/Application Support/AddressBook directory and called AddressBook-v22.abcddb.  In order to interfaces with Address you can use the sqlite3 command followed by the path to the database itself.  For example, the following command will simply dump you into a sqlite interactive command line environment:
sqlite3 ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb
Once in the environment you can view databases, manually work with the data, etc.  The basic information about a contact is stored in the ZABCDRECORD table.  You can view the contents of this table using the following command:
select * from ZABCDRECORD
If you type the following then you’ll list all of the contents of the ZABCDEMAILADDRESS table:
Notice that here you’ll see email addresses, but also a lot more information.  To figure out which column of your table that you want to look at to just see the email addresses, use the following command at the sqlite3 interactive prompt (noting that it’s case sensitive):
.header ON
Now that we know that we want to constrain our output to ZADDRESS, go ahead and use the following command to simply list the email addresses:
You can also run the above query from a single command, rather than using the interactive prompt:
sqlite3 ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb “select DISTINCT(ZADDRESS) from ZABCDEMAILADDRESS”
Or, if you would rather work with tab delimited text (and we will want to for a future article) and pull all of the information for these users (which would need to be cross referenced against their unique ID such as ZSERIALNUMBER for other pertinent information btw):
sqlite3 -separator ‘t’ ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb ‘select * from ZABCDEMAILADDRESS’
Next we’re going to simply dump the contents of our file out to a text file called alladdys.txt, stored in /Scripts/alladdys.txt:
sqlite3 ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb “select DISTINCT(ZADDRESS) from ZABCDEMAILADDRESS” > /Scripts/alladdys.txt
Now we’re going to go ahead and limit the output to addresses including and dump that into a file in the same folder called specificaddy.txt, which allows us to check Address Book to see if an email address is there (might be useful later):
sqlite3 -separator ‘t’ ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb ‘select DISTINCT(ZADDRESS) from ZABCDEMAILADDRESS’ | grep > /Scripts/specificaddy.txt
While we were specifically looking for Address Book information, it’s worth noting that sqlite is fairly prolific in Mac OS X.  It is used with iCal, which stores databases in ~/Library/Calendars/Calendar Cache.  It is also used for some things in, which stores information in ~/Library/Mail/Envelope Index.  Safari also stores information about RSS feeds in ~/Library/Syndication/Database3.

Address and Exchange Contacts

Over the years Apple has slowly been adding Exchange functionality to a number of their products, quietly.  While Snow Leopard  is reported to add even more functionality there are still a number of things you can do with Exchange from the Mac OS X client.  For example, Address Book can pull information from your Exchange contacts.  This isn’t to say that every single field will work, but the basics do work – and pretty well.   To connect to your Exchange server from Address Book, open the program and then open the Preferences menu.  From the General tab check the box for Synchronize with Exchange as seen here:
Address Book Synchronize to Exchange
Address Book Synchronize to Exchange
 Now click on the Exchange… button and enter your user name, password and Outlook Web Access Server (OWA Server, or if you only have one Exchange server, the name/IP of the host).  For the Outlook Web Access Server you’ll also want to make sure you have the Fully Qualified URL of the host you use to access your mail, rather than just the IP address for example.  If you would like for synchronizations to occur automatically go ahead and click on the Synchronize Every Hour checkbox.  
Exchange Sync Settings
Exchange Sync Settings
  Saying that Apple has been quietly developing it and saying that it works like a charm though, are two separate topics.  Don’t expect to be able to also synchronize with other services.  This is a recipe for mass duplications of contact data.  Also, don’t expect it to work flawlessly.  It can be problematic, although not always.  In short – if you’re going to try this, make good backups early and often.

Mac OS X Server 10.5: LDAP ACLs

I originally posted this at In Leopard, Workgroup Manager supports rudimentary ACLs for the LDAP database. We’re all familiar with Access Control Lists by now. Especially in the Mac OS X Server community. However, we might not all be familiar with ACLs as they’re implemented in LDAP. But we should be, because LDAP is being used more and more as an address book, and with the new Directory application being shipped in Leopard it is conceivable that environments aren’t just going to use ACLs to secure LDAP but they’re also going to use them to allow users to self update their information in the directory. So in the interest of security and making the most out of the technologies build into LDAP, let’s cover LDAP ACLs for a bit. So to push beyond what you can do in Workgroup Manager, let’s take a look at building out more finely grained ACLs manually. First, like with most things in LDAP ACLs are configured using the /etc/openldap/slapd.conf file. Below is the pertinent portion of this file that we will be looking at: # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:// # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! Now, if we remove the commented out portions of the file or add more lines we can start to limit who has access to read and/or change what information in the LDAP database. Keep in mind that you always want to back up your slapd.conf file prior to doing so. You can control access to each element in the database. Each ACL has an “access to” which is the elements in the LDAP database that you are granting or denying access for and then a “by” portion that lists who can do what to that portion of the database. An entire ACL can be listed on one line, as is done with policies that have only one user or group associated to them. For example, the following line gives anyone and everyone read access to the database: access to dn.base=”” by * read For ease of use and reviewing, we typically put the “access to” on one line and the subsequent users or groups with access in their own “by” lines for more complicated ACL rule sets. Slapd parses the file in such a way that it realizes that “access to” means the beginning of a new ACL. The following is an example of some more complicated ACLs: access to attrs=userPassword by dn="cn=users,dc=318,dc=com" write by self write by * compare access to * by dn="cn=computers,dc=318,dc=com" write by users read by * auth Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. In the above example, a user is able to write to their own userPassword record. This means that the user is also able to auth, compare, search and read that record. ACLs are prosessed from top to bottom. This makes it important to put specific ACLs and by statements above more general ones. ACLs that restrict access to the userPassword attribute, followed by one applicable to *, that is, the entire LDAP database. In the above example, placing the userPassword ACL first causes the rule that allows users to change their own passwords to process before the wildcard that specifies everyone. When a * is used as a wildcard in the access to line of slapd.conf it means the entire database or tree of the LDAP database. When the * is used in the by line it typically denotes all users. Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. These two points, the first match wins rule and the inclusive nature of access levels, are crucial to understanding how ACLs are parsed. They also are important for making sure your ACLs don’t lead to either greater or lesser levels of access than you intend in a given situation. It can be time consuming to go through every possible attribute by group and determine who has access to what. However, if you want to have users updating their own addresses, phone numbers, and other information, as can be done with the Directory application, this is often one way to accomplish this goal. You could also provide help desk users the ability to update the database using the Directory application but not allow them to access other records in the LDAP database, such as group memberships. Having a very granular ACL environment for records can also allow you to obtain a maximum level of security. This can also be put into the schema in order to force replication between hosts. Keep an eye out for that article at a later date. ;) For what it’s worth, at 318 we’ve found that commenting out each ACL helps us to keep track of who did what, why and what they were thinking when they did it. Happy OD everyone!!!