Tag Archives: web

Mac OS X Mac OS X Server Mac Security Mass Deployment Xsan

Yosemite Server And Logs

OS X Yosemite running the Server app has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for OS X Server called server setup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in Yosemite Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. And the scripts tend to change year over year/release over release.

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of OS X Server intend for certain tasks to occur.

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirectorybackup (that still requires a password). But what I haven’t seen in all of these logs is bumping up the logging level for services before performing tasks, so that you can see a verbose output of what’s going on. To do this, it looks like we’re going service-by-service. So let’s look alphabetically, starting with Address Book:

sudo serveradmin settings addressbook:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings addressbook:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings addressbook:ErrorLogFile=error.log

You can change either by changing what comes after the = sign. Next is afp. This service logs output to two places. The first is with errors to the service, using /Library/Logs/AppleFileService/AppleFileServiceError.log, the path designated in the following:

sudo serveradmin settings afp:errorLogPath = “/Library/Logs/AppleFileService/AppleFileServiceError.log”

The second location logs activities (open file, delete file, etc) rather than errors and is /Library/Logs/AppleFileService/AppleFileServiceAccess.log, defined using:

sudo serveradmin settings afp:activityLogPath = “/Library/Logs/AppleFileService/AppleFileServiceAccess.log”

The activity log is disabled by default and enabled using the command:

sudo serveradmin settings afp:activityLog = yes

The events that trigger log entries are in the afp:loggingAttributes array and are all enabled by default. There are no further controls for the verbosity of the afp logs. The next service is calendar. Similar to address book, the caldav server uses DefaultLogLevel to set how much data gets placed into logs:

sudo serveradmin settings calendar:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings calendar:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings calendar:ErrorLogFile=error.log

You can changing either by changing what comes after the = sign.
Profile Manager is called devicemgr in the serveradmin interface and I’ve found no way to augment the logging levels. Nor does its migration script ( /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/80-devicemgrmigration.sh ) point to any increased logging during migration.

The dirserv (aka Open Directory) uses the slapconfig back-end, so I use slapconfig to increase logging:

sudo slapconfig -enableslapdlog

The DNS service uses named.conf, located in /etc to set log levels and has no serveradmin settings for doing so. Here, use the logging section and look for both the file setting (by default /Library/Logs/named.log) for where the log is stored as well as the severity setting, which can set the logging levels higher or lower.

By default Messages, or iChat Server, logs a lot. See the following for what is logged:

sudo serveradmin settings jabber:logLevel = “ALL”

Adding the -D option to the LaunchDaemon that invokes jabber will increase the logs. Logging long-term is handled in each of the xml files that make up the features of jabber. See the Logconfiguration section of the c2s file via:

cat /Applications/Server.app/Contents/ServerRoot/private/etc/jabberd/c2s.xml

The mail service has a number of options for logging, much of which has to do with the fact that it’s a patchy solution made up of postfix, etc. Global log locations are controlled using the mail:global:service_data_path key, which indicates a path that logs are stored in (as usual many of these are in /Library/Server):

sudo serveradmin settings mail:global:service_data_path = "/Library/Server/Mail"

To see the virus database logging levels (which should usually be set to warn):

sudo serveradmin settings mail:postfix:virus_db_log_level

To see the spamassassin logging levels:

sudo serveradmin settings mail:postfix:spam_log_level

To see the actual postfix logging level:

sudo serveradmin settings mail:postfix:log_level

To enable timestamps on logs:

sudo serveradmin settings mail:imap:logtimestamps = yes

To set the dovecot logging to info:

sudo serveradmin settings mail:imap:log_level = “info”

To set increased logging per function that dovecot performs, see the config files in /Applications/Server.app/Contents/ServerRoot/private/etc/dovecot/default/conf.d, each of which has a logging section to do so.

The NetBoot service is simple to configure logging for, simply set the netboot:logging_level to HIGH (by default it’s MEDIUM):

sudo serveradmin settings netboot:logging_level = “HIGH”

The Postgres service uses a log directory, configured with postgres:log_directory:

sudo serveradmin settings postgres:log_directory = “/Library/Logs/PostgreSQL”

The /private/etc/raddb/radiusd.conf has a section (log {}) dedicated to configuring how the radius service logs output.

The Xsan service logs output per volume to both the System Log and volume-based log files, stored in /Library/Preferences/Xsan/data.

The smb service has a file /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist with a key for log level that can be used for more verbose output of the service.

The PPTP VPN service logs output to the file specified in vpn:Servers, configured with these:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:LogFile = “/var/log/ppp/vpnd.log”

By default, verbose logging is enabled, which you can see with:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:VerboseLogging

The last service is web (Apache). The default access logs are per-site, with a key called customLogPath existing for each. The defaultSite uses the following for its logs:

sudo serveradmin settings web:defaultSite:customLogPath

Swap out the defaultSite with another site to see its log paths. There’s also a key for errorLogPath that shows errors. These are per-site so that administrators can provide access to logs for the owners of each site and not fear them having access to logs for other users. Global error logs are stored in /private/var/log/apache2/error_log as defined in /private/etc/apache2/httpd.conf. Find LogLevel in this file and set it to configure how in depth the logs will be, using debug for the most verbose and info, notice, warn, error, crit, alert, and emerg to get incrementally less information.

Additionally the log formats can be set in /private/etc/apache2/httpd.conf, allowing administrators to configure Yosemite Server’s built-in web service to conform to the standards of most modern web log analyzers.

Conclusion

Overall, there’s a lot of information in these logs and administrators can spend as much time reviewing logs as they want. But other than standard system logs, the output is typically configured on a service-by-service basis. Some services offer a lot of options and others offering only a few. Some services also offer options within the serveradmin environment while others use their traditional locations in their configuration files. I’ll end this with a warning. There can also be a lot of output in these logs. Therefore, if you set the logging facilities high, make sure to keep a watchful eye on the capacity of the location you’re writing logs out to. The reason I looked at paths to logs where applicable was because you might want to consider redirecting logs to an external volume when debugging so as not to fill up a boot volume and cause even more problems than what you’re likely parsing through logs looking to fix…

public speaking

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 Server.app: We show you how to use server.app 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

cloud

Hosting Web Sites in Amazon Web Services

Amazon S3 now allows administrators to host simple web sites. Previously, you could host images, videos and other files using S3 buckets, but now you can host full sites. To do so you will need only configure a webroot and some error documents. To get started:

  1. Log into the Amazon S3 Management Console
  2. Right-click on an Amazon S3 bucket
  3. Open the Properties panel
  4. Configure your webroot
  5. Click on the Website tab
  6. Configure error documents in the Website tab
  7. Click Save

Pretty easy, right? But what if you need to configure the php.ini file or add MIME types, etc. Notice that at the start of this I said “simple.” I’m sure more features are to follow, but for now S3 is mostly appropriate for very simplistic sites.

Mac OS X Server

Podcast Producer Web Controller

By default, Podcast Producer clients submit podcasts to a Mac OS X Server using the Podcast Capture application, as you can see in the comic from yesterday. This is a seamless integration, if a bit Mac-centric. But there is also a web controller for Podcast Producer that allows you to submit podcasts via a web interface, rather than through Podcast Capture and allows you to control cameras using the portal. If you have a number of Windows or Linux stations or just want to communicate over a web browser this is a great option to bolt on to Podcast Producer deployments. Find it on the Apple Education for IT Professionals website:
http://www.apple.com/education/it-professionals/webcontroller/

sites

TextEdit for the Web

These days it seems like there’s a low-cost or free alternative to everything up on the web/in the clouds. This could be something like gMail for email, OpenDNS for DNS or even one of the many sites that provides users with file storage. Now enter j.otdown.com. Using this service you can type text to your hearts content. When you stop typing a url will be generated and automatically saved. You can then use that URL to revisit your document at a later time.

You can also use the Share button to then email the link to others. For example, this document was created and shared by yours truly. It’s got a lot of useful information in it… ;)