Tag Archives: jabber

Mac OS X Server

Configure Messages Server in Mavericks Server

Getting started with Messages Server couldn’t really be easier. Messages Server in Mavericks Server uses the open source jabber project as their back-end code base (and going back, OS X has used jabber since the inception of iChat Server all the way through Server 3). The jabberd binary is located at /Applications/Server.app/Contents/ServerRoot/private/var/jabberd and the autobuddy binary is at /Applications/Server.app/Contents/ServerRoot/usr/bin/jabber_autobuddy. Given the importance of having multiple binaries that do the same thing, another jabberd binary is also stored at /Applications/Server.app/Contents/ServerRoot/usr/libexec/jabberd, where there are a couple of perl scripts used to migrate the service between various versions as well. Note that the man page says it’s in /etc. But I digress.

Setting up the Messages service is simple. Open the Server app and click on Messages in the Server app sidebar.

Screen Shot 2013-10-05 at 3.42.19 PM

I brought you some supper but if you’d prefer a lecture, I’ve a few very catchy ones prepped…sin and hellfire… one has man page lepers.

Once open, click on the checkbox for “Enable server-to-server federation” if you have multiple iChat, er, I mean, Messages servers and then click on the checkbox for “Archive all chat messages” if you’d like transcripts of all Messages sessions that route through the server to be saved on the server. You should use an SSL certificate with the Messages service. If enabling federation so you can have multiple Messages servers, you have to. Before enabling the service, click on the name of the server in the sidebar of Server app and then click on the Settings tab. From here, click on Edit for the SSL Certificate (which should be plural btw) entry to bring up a screen to select SSL Certificates.

Screen Shot 2013-10-05 at 3.49.12 PM

Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious.

At the SSL Certificates screen (here it’s plural!), select the certificate the Messages service should use from the available list supplied beside that entry and click on the OK button. If you need to setup federation, click back on the Messages service in the sidebar of Server app and then click on the Edit button. Then, click on the checkbox for Require server-to-server federation (making sure each server has the other’s SSL certificate installed) and then choose whether to allow any server to federate with yours or to restrict which servers are allowed. I have always restricted unless I was specifically setting up a server I wanted to be public (like public as in everyone in the world can federate to it, including the gorram reavers that want to wear your skin).

Screen Shot 2013-10-05 at 3.50.37 PM

This is what I do, darlin’. This is what I do.

To restrict the service, then provide a list of each server address capable of communicating with your server. Once all the servers are entered, click the OK button.

Obviously, if you only have one server, you can skip that. Once the settings are as you wish them to be, click on the ON/OFF switch to light up the service. To see the status of the service, once started, use the fullstatus option with serveradmin followed by the jabber indicator:

sudo serveradmin fullstatus jabber

The output includes whether the service is running, the location of jabber log files, the name of the server as well as the time the service was started, as can be seen here:

jabber:state = "RUNNING"
jabber:roomsState = "RUNNING"
jabber:logPaths:PROXY_LOG = "/private/var/jabberd/log/proxy65.log"
jabber:logPaths:MUC_STD_LOG = "/var/log/system.log"
jabber:logPaths:JABBER_LOG = "/var/log/system.log"
jabber:proxyState = "RUNNING"
jabber:currentConnections = "0"
jabber:currentConnectionsPort1 = "0"
jabber:currentConnectionsPort2 = "0"
jabber:pluginVersion = "10.8.211"
jabber:servicePortsAreRestricted = "NO"
jabber:servicePortsRestrictionInfo = _empty_array
jabber:hostsCommaDelimitedString = "mavserver.pretendco.lan"
jabber:hosts:_array_index:0 = "mavserver.pretendco.lan"
jabber:setStateVersion = 1
jabber:startedTime = ""
jabber:readWriteSettingsVersion = 1

There are also a few settings not available in the Server app. One of these that can be important is the port used to communicate between the Messages client and the Messages service on the server. For example, to customize this to 8080, use serveradmin followed by settings and then jabber:jabberdClientPortSSL = 8080, as follows:

sudo serveradmin settings jabber:jabberdClientPortSSL = 8080

To change the location of the saved Messages transcripts (here, we’ll set it to /Volumes/Pegasus/Book:

sudo serveradmin settings jabber:savedChatsLocation = “/Volumes/Pegasus/Book”

To see a full listing of the options, just run settings with the jabber service:

sudo serveradmin settings jabber

The output lists each setting configurable

jabber:dataLocation = "/Library/Server/Messages"
jabber:s2sRestrictDomains = no
jabber:jabberdDatabasePath = "/Library/Server/Messages/Data/sqlite/jabberd2.db"
jabber:sslCAFile = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.chain.pem"
jabber:jabberdClientPortTLS = 5222
jabber:sslKeyFile = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.concat.pem"
jabber:initialized = yes
jabber:enableXMPP = no
jabber:savedChatsArchiveInterval = 7
jabber:authLevel = "STANDARD"
jabber:hostsCommaDelimitedString = "mavserver.pretendco.lan"
jabber:jabberdClientPortSSL = 5223
jabber:requireSecureS2S = no
jabber:savedChatsLocation = "/Library/Server/Messages/Data/message_archives"
jabber:enableSavedChats = no
jabber:enableAutoBuddy = no
jabber:s2sAllowedDomains = _empty_array
jabber:logLevel = "ALL"
jabber:hosts:_array_index:0 = "mavserver.pretendco.lan"
jabber:eventLogArchiveInterval = 7
jabber:jabberdS2SPort = 0

To stop the service:

sudo serveradmin stop jabber

And to start it back up:

sudo serveradmin start jabber

It’s also worth noting something that’s completely missing in this whole thing: Apple Push Notifications… Why is that important? Well, you use the Messages application to communicate not only with Mac OS X and other jabber clients, but you can also use Messages to send text messages. Given that there’s nothing in the server that has anything to do with texts, push or anything of the sort, it’s worth noting that these messages don’t route through the server and therefore still require an iCloud account. Not a huge deal, but worth mentioning that Messages server doesn’t have the same updates built into the Messages app. Because messages don’t traverse the server, there’s no transcripts.

Mac OS X Server Mac Security Mass Deployment

Logs, Scripts and OS X Mountain Lion Server

OS X Mountain Lion 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 Mountain Lion Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data, such as /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/30-ipfwmigrator. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python.

Additionally, there’s a directory /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/ that is full of scripts for migrating services in OS X Server, helpful for even services that have been seemingly deprecated.

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. One such example is /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/loggather.sh, used to grab logs. Here, you can learn the locations of certain logs as well as rudimentary stackshot commands. This is where I started calling stackshot before I did Server installs (or during), using the following command, which creates a custom text file containing :

/usr/libexec/stackshot -i -f /Library/Logs/ServerSetup_StackShot_KRYPTED.txt

This is also where I learned that I can tail /tmp/SetupLogs.tgz during some installs to be able to watch what’s going on during the installation process:

tail -f /tmp/SetupLogs.tgz

Looking At Each Service

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. 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:

sudo serveradmin settings mail:imap:log_level = "warn"

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 san service (Xsan) 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 Mountain Lion 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…

Mac OS X Server

Changes in Mountain Lion Server

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server…

I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work.

Many services also got some pretty nice updates. These include:

  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.

Configuring Websites in Server app

The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.

Configuring Alerts in Mountain Lion Server

The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future.

Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below –> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.

Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

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

Ubuntu Unix

Server Admin on Linux

Apple recently announced the end of the Apple Xserve. The data center is a funny thing, and being such rack space is critical to most who spend a lot of time there. Many of the previous Xserve customers will continue to buy Mac Pro’s and use them in racks as tall Xserves. Others will purchase Mac Mini’s and use them for certain situations. But many will move on to using the same iron in the data center that they use for everything else, finding a way to duplicate or replace the functionality that was previously in the Xserve with something else.

Server Admin is not going to run on Linux. But you can get kinda’ close and if you really miss the GUI for DNS (not likely) and the other services (possible and in some cases highly likely) then you can hax0r the stuff to look as much like Server Admin as you want. In fact, given the number of developers and the open source nature, the tools available on Linux are likely to even blow away what you could do before. However, there’s a much steeper learning curve and that’s why many (not all) in the Xserve camp have stuck it out with Apple all these years.

The easiest and most mature of the solutions that can be used here is Webmin. We’re going to look at installing Webmin on an old Dell Dimension 5150 that’s running Ubuntu Server 10. Warning, there’s gonna’ be some command line here to get ya’ started, but feel free to cut and paste.

First up, install the webmin dependencies. Dependencies are to many the most frustrating thing about working with Open Source software. But never fear, the Webmin team has posted their dependencies as perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime and libio-pty-perl. So, let’s install those with elevated privileges, using apt-get:

apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl

Next, let’s install Webmin itself. Download Webmin:

wget http://prdownloads.sourceforge.net/webadmin/webmin_1.520_all.deb

If that fails, check the version at the Webmin site and re-run using the correct URL, listed on the site. Once you’ve downloaded, it’s time to install. One of the reasons (in my opinion) that Ubuntu is so popular is that like Apple they use a package-type of format for installers. Therefore, think of the dpkg command like the installer command in Mac OS X when used with the –install or -i operator. So assuming your working directory is where you downloaded that package to (*.deb)

dpkg -i webmin_1.520_all.deb

Once it’s finished fire up a web browser and go to port 10000 on your box. You should be prompted to authenticate, which can be done using root as the username and the root password of your box as the password. Once done, go to the module page or search for a third party module if the package you’d like isn’t include, and download the modules you need.

I’m not a huge fan of Webmin, but I’ve heard a lot of talk about “wouldn’t it be great if there were something similar to Server Admin”. Well, the way Roles work in Windows Server is similar and Windows Server can pretty much do anything (include make me coffee). If you are averse to Microsoft servers and/or paying per CAL for licensing, plugging modules into Webmin is pretty darn close as well. Looking at services included in Mac OS X Server, Webmin can manage FTP (Frox/WU-FTP/ProFTPd), NFS, Samba, SSH, SpamAssassin, Squid, Apache (and Webalizer), VPN (PPP/PPTP/IPsec), Mail (Dovecot/Postfix/Sendmail/Procmail/Majordomo), database (MySQL/PostgreSQL), Shorewall, LDAP w/ Kerberos, DHCP, Bind, Jabber, CVS/Subversion, VNC and even Bacula (replacing that Time Machine server concept).

You have way more choices (which isn’t always a good thing). Sure, Webmin is not nearly as pretty as Server Admin and it has many of the same issues of interpreting what are in config files and developing a WTF complex if you make a change in one place vs. the other. But it can also manage VMs and do a lot of other things (ie – monitoring). I still prefer Mac OS X Server for a lot of things, but if someone adds Netatalk (trivial), ports the Apple .schema file in and DAViCal/CardDAV, you’ve got a new version of spaghetti open source pretty similar to Server Admin. A little CSS and you can even make it look just like Server Admin.

Not everyone is going to want to use Ubuntu. I personally end up using Redhat more than I do any other flavor of Linux. For Redhat users, getting Webmin installed is actually even easier. Simply run rpm, specifying the package and you’re off to the races:

rpm -U webmin-1.520-1.noarch.rpm

Finally, I really and truly do not condone a knee-jerk reaction to Apple’s decision to terminate the Xserve. Unless Sarah Connor can do something about it I don’t think it’s coming back. If you absolutely have to move certain services to a different 1U box, then here ya’ go. Otherwise, stay with those new MacPro Servers, you’ll be happier with them in the long run!

Mac OS X Server

Mac OS X Server 10.5: Customizing the iChat Server Welcome Message

I originally posted this at http://www.318.com/TechJournal

Customizing the welcome message to new users of your iChat server is a fairly simple task. For this, we’ll look into the jabber configuration because jabber is the Open Source package that iChat Server is built on.

When you first setup jabber the /etc/jabber directory will be created. Inside this folder will be a file called jabber.xml. If you open the jabber xml file and look for the “welcome” tag then anything between the "welcome" and"/welcome" will be the information that is shown in a welcome screen when a new user signs onto the iChat server. Before you edit the /etc/jaber/jabber.xml file make sure to back it up.

For this example we will have all new users receive a message that says Welcome to the 318 iChat Server. To do this, delete or comment out the information between the existing welcome tags and add the following information:

"welcome"
"subject"318 iChat Server"/subject"
"body"Welcome to the 318 iChat Server"/body"
"/welcome"

Save the jabber.xml file and you’ve now customized the welcome message for your iChat server.

Note, for the purpose of this article the < and > have been replaced with quotes (”). However, you will need to use the < and > in your environment while using the Jabber.xml file.