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.
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.
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.
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 org.net-snmp.snmpd, 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 192.168.210.99 in the following example):
snmpwalk -On -v 1 -c COMMUNITY 192.168.210.99
krypted October 23rd, 2013
Posted In: Mac OS X 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?
krypted August 23rd, 2012
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:
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
krypted April 5th, 2012
Posted In: public speaking
Tags: Address Book, Apache, app, Apple Configurator, caldav, carddav, DeployStudio, DNS, FTP, iCal, iChat, iphone configuration utility, jabber, lion server, Mac OS X, MacTech, mdm, mobile device management, NetBoot, NetRestore, new york, server, Snow Leopard, web
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:
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/wipeDB.sh 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:
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 Utility.app/Contents/Resources/stroke 127.0.0.1 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.
krypted January 4th, 2012
Tags: 127.0.0.1, Address Book, backup, caldav, calendar, change location, change postgres directory, create a new user, createuser, data directory, devicemgr, device_management, Enable network listener, lion server, os 10.7 server, pg_dump, port scan, postgres, PostgreSQL, profile manager, psql, public view, query, roundcube, roundcubemail, roundcubemail.sql, select, serveradmin, socket, SQL, sqlite3, stroke, wiki, _postgres
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:
krypted December 16th, 2009
krypted December 2nd, 2009
Posted In: Mac OS X
If you grew accustomed to using Directory.app 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 Directory.app in Snow Leopard. If you were using Directory.app 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…
krypted August 29th, 2009
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 Book.app 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:
select * from ZABCDEMAILADDRESS
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):
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:
“select DISTINCT(ZADDRESS) from ZABCDEMAILADDRESS”
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”
sqlite3 -separator ‘t’ ~/Library/Application Support/AddressBook/AddressBook-v22.abcddb ‘select * from ZABCDEMAILADDRESS’
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 email@example.com 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 firstname.lastname@example.org > /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 Mail.app, which stores information in ~/Library/Mail/Envelope Index. Safari also stores information about RSS feeds in ~/Library/Syndication/Database3.
krypted April 22nd, 2009
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:
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.
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.
krypted February 17th, 2009
I originally posted this at http://www.318.com/TechJournal
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.
# 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!!!
krypted November 14th, 2007
Posted In: Mac OS X Server