By default, MySQL comes with a root user configured. You can also create additional users, change passwords for users, and assign what databases and tables they have access to. From MySQL, you can can create a basic user using the CREATE USER statement, providing a user, a location, and then using IDENTIFIED BY followed by a password. In production, this would look similar to the following, using krypted as the user and mysecretpassword as the password:
CREATE USER 'krypted'@'localhost' IDENTIFIED BY 'mysecretpassword';
Once you’ve created a user, you’ll want to assign what the user can access. Here, the * wildcard is pretty handy. In the following command, we’ll use the GRANT statement along with ALL PRIVILEGES to give this new krypted user access to all of the databases running on MySQL:
GRANT ALL PRIVILEGES ON * . * TO 'krypted'@'localhost';
Pretty easy so far. Just flush the permissions with the FLUSH PRIVILEGES statement and krypted’s now all good to access anything that exists in MySQL when the command was run.
FLUSH PRIVILEGES;
Once you’ve flushed, you can see what a user can access using the SHOW GRANTS statement:
SHOW GRANTS FOR 'krypted'@'localhost';
If you create new databases, do so again. To login as the user, you can then just run mysql followed by the -u option to define the user:
mysql -u krypted -p
To remove permissions, use the REVOKE statement. Let’s remove the ALL PRIVILEGES from krypted:
REVOKE ALL PRIVILEGES ON *.* FROM 'krypted'@'localhost';
To delete a user, use the DROP statement, and then USER, followed by who we’re deleting:
DROP USER ‘krypted’@‘localhost’;
If you were then going to create the user and provide a different level of privileges you could replace ALL PRIVILEGES with one of the following:

ALL PRIVILEGES: Gives the user full access to a database (or all included with a wildcard)

CREATE: Gives a user the ability to create new databases or tables within a database the access is provided

DROP: Gives a user the ability to use the DROP statement to remove tables or databases

DELETE: Gives a user the ability to delete rows from tables

GRANT OPTION: Gives a user the ability to add and remove privileges for other users

INSERT: Gives a user the ability to create rows into tables using the INSERT statement

SELECT: Gives a user the ability to use SELECT statements (similar to read in POSIX)

Error 1006.0005 can appear on a Qlogic fibre channel switch when using ACL zones. If you don’t need ACL zones, then the easiest thing to do here is to swap the offending zone back to a soft zone. To do so, open the Qlogic Switch and use the Edit menu to select “Edit Zoning …”
From the zone editor, right-click on the zone to change and click on Set Zone Type.
From the Set Zone Type pop-up, click on the option for Soft.
Save the zoning and provided that you can actually use soft zones you are done. Now, what if you can’t use soft zoning? In that case, I find that this error specifically comes up when you have a device in a soft and ACL-based zone. To rectify that, either switch the soft zone to ACL or define the port in the ACL zone and the WWN in the soft zone.

By default, when you require an SSL certificate in IIS on an Exchange server, if users hit the page without providing an https:// in front they will get an error. Rather than require certificates, it’s better in most cases to redirect unsecured traffic to a secured login page. In order to do so, first configure the redirect. To do so, open IIS Manager and click on the Default Web Site.
At the bottom of the pane for the Default Web Site, click Features View if not already selected.
Then open HTTP Redirect. Here, check the box for “Redirect requests to this destination” and provide the path to the owa virtual directory (e.g. https://krypted.com/owa).
In the Redirect Behavior section, select the “Only redirect requests to content in this directory (not subdirectories)” check box and set the Status code to “Found (302)”.
In the Actions pane to the right of the screen, click Apply. Then click on Default Web Site again and open the SSL Settings pane. Here, uncheck the box for Require SSL.
Once done, restart IIS by right-clicking on the service and choosing Restart or by running iisreset:
iisreset /noforce
Next, edit the offline address book web.config file on the CAS, stored by default at (assuming Exchange is installed on the C drive) C:\Program Files\Microsoft\Exchange Server\\ClientAccess\oab. To edit, right-click web.config and click Properties. Then click Security and then Edit. Under Group, click on Authenticated Users. Then click Read & execute for Authenticated Users in Permissions. Then click OK to save your changes.
Finally, if you have any issues with any messages not working, start the IIS Manager. Then browse to the virtual directories and open HTTP Redirect. Then uncheck “Redirect requests to this destination” and click Apply. When you’re done, restart IIS again and test the ability to send and receive emails to make sure that mail flow functions without error from within the web interface.

iChat Server was sooooo easy to configure. iChat Server is now Messages Server. Both use the open source jabber project as their back-end code base. Lucky us, all Apple did in the latest iteration is change the name of the service in the Server app, leaving the command line effectively untouched. The paths to things serverish have changed. The jabberd binary is now 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. 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.

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

“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).

“And I think calling him that is an insult to the psychotic lowlife community.”

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 = "32"
jabber:currentConnectionsPort1 = "32"
jabber:currentConnectionsPort2 = "0"
jabber:pluginVersion = "10.8.177"
jabber:servicePortsAreRestricted = "NO"
jabber:servicePortsRestrictionInfo = _empty_array
jabber:hostsCommaDelimitedString = "kaylee.pretendco.com"
jabber:hosts:_array_index:0 = "kaylee.pretendco.com"
jabber:setStateVersion = 1
jabber:startedTime = "2012-08-02 02:53:26 +0000"
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:s2sRestrictDomains = no
jabber:authLevel = "STANDARD"
jabber:savedChatsLocation = "/Library/Server/Messages/Data/message_archives"
jabber:sslKeyFile = ""
jabber:enableXMPP = yes
jabber:initialized = yes
jabber:jabberdClientPortSSL = 5223
jabber:sslCAFile = ""
jabber:requireSecureS2S = no
jabber:savedChatsArchiveInterval = 7
jabber:hostsCommaDelimitedString = "zoe.pretendco.com"
jabber:jabberdDatabasePath = "/Library/Server/Messages/Data/sqlite/jabberd2.db"
jabber:jabberdS2SPort = 5269
jabber:hosts:_array_index:0 = "zoe.pretendco.com"
jabber:jabberdClientPortTLS = 5222
jabber:enableSavedChats = no
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.

I was recently experimenting with Parallels to run some Lion Server VMs and I must have wasted a couple of hours trying to get Lion Server up and running as a Profile Manager host in a VM. Then I had the good sense to complain to Arek Dreyer, who I’m guessing had complained to Andrina Kelly who had, well, answered the riddle. Apparently you need to enable a second core in order to promote to an Open Directory Master in Parallels. To enable said second CPU, open Parallels, go to the configure screen for the VM and then make sure CPUs is set to some number higher than 1. Who knew, right?

Server.app in Lion is a pretty good app for most tasks. But I find myself frequently doing things that I don’t think developers intended me to do. One such item is setting up and tearing down Open Directory to test various iterations of enabling a master. I frequently use slapconfig to destroyldapserver:
slapconfig -destroyldapserver
Doing so almost immediately allows me to demote an Open Directory master to a stand-alone server and then repromote the server to a master or replica for testing purposes. If you do this, then Open Directory cannot be set back up using Server.app. The fix is to use Server Admin to repromote your server back to an Open Directory master and then use Server Admin to more graciously demote the server back to stand-alone. Until you do this, the Server.app will error out on Open Directory promotions that the server is already an Open Directory master.
A change I’ve made to my workflow when nukin’ and pavin’ OD is to just use Server Admin for the paving part. If you demote with Server Admin you won’t have these issues. Hope this helps someone who finds similar wonkiness.

With Mac OS X 10.5.8 and 10.6.x, Mac OS X Server, Xsan, Final Cut Server and a number of other serialized products were switched to a whole new solution for managing serial numbers: a newly redone serialnumberd. If you run otool against serialnumberd in 10.5.7 and below you’ll notice no dependencies; it stood alone so to speak. If you run otool against the latest and greatest then you’ll notice that it has a number of dependencies that run the gambit of otherwise unthinkable services. This caused minor growing pains during the summer with multihomed network connections, maximum number of clients and other aspects of servers with certain solutions, but that got ironed out quickly with the 10.5.8v1.1 and 10.6.1.
But there have been some minor issues I’ve seen still, mostly due to installer packages not holistically cleaning up old artifacts with regards to daemons that manage serial numbers (likely due to their author being concerned about the potential for other services to have dependencies on them). This is a problem that seems to manifest itself more frequently if you are running both Mac OS X Server and Xsan on the same host (which is basically all metadata controllers, etc) and have upgraded from Xsan 1.x to 2.x and potentially upgraded from Mac OS X 10.4.x to 10.5.x and ultimately to 10.6.x.
The /System/Library/StartupItems/SerialNumberSupport StartupItem initially invoked the SerialNumberSupport daemon. However, that’s no longer needed for any product that I’m aware of. Therefore, you can stop it using the SystemStarter command and telling it to ‘stop SerialNumberSupport’:

SystemStarter stop SerialNumberSupport

SerialNumberSupport overall is deprecated and so if stopping it does not cause any adverse effects but does resolve some form of volume issues you might be having with your Xsan then you can also move it off somewhere that it can’t be overly troublesome, like your desktop:

Additionally, since serialnumberd is invoked by com.apple.serialnumberd.plist in /System/Library/LaunchDaemons then in many cases you do not need the /System/Library/LaunchDaemons/com.apple.SNServer.plist. If it is loaded and you are still having problems then try unloading it using launchctl. If your problems are gone then so should the SNServer, so consider moving it using:

These artifacts are likely left behind for a reason. So before you go removing them, check that a temporary stop of them resolves issues without adversely effecting other services. There is a good reason that not everything gets removed, although sometimes they can have unintended consequences…