Software

MySQL Enterprise Monitor is a really good tool to see what's going on in the DB. At least I'd like to give my DB-box all the possible resources, I'm running the Service Manager -part in another server.

Sometimes there is a need to upgrade servers. This time it moving other roles out of the way was piece-of-cake, except the Service Manager. In the entire Internet, there is no spot-on information about how to do it in detail. The only really relevant information I could find is B.5. Backing up MySQL Enterprise Service Manager in the MySQL documentation. In the doc they manage to describe how to back things up, but not really how to restore anything.

I did the operation in following steps:

1. Fresh installation of Service Manager in the new server
• I chose not to configure anything and ended the installation there
2. Backup of the data as described in the doc:
   mysqldump --single-transaction -uservice_manager -p -P13306 -h127.0.0.1 mem > mem.dump
   
3. Restore of data into the new server using command like:
   /opt/mysql/enterprise/monitor/mysql/bin/mysql -u service_manager -p -P13306 -h 127.0.0.1
   
4. In the DB-server the Enterprise Monitor Agent needs to be reconfigured to send information to a new Service Manager
1. Edit file /opt/mysql/enterprise/agent/etc/mysql-monitor-agent.ini
2. Confirm value of agent-mgmt-hostname
   
3. Confirm value of aggr-mem-baseurl
   
5. After these changes a login to the newly setup Service Manager showed the DB as fully functional
   

Hope this helps somebody.

Current Linux implementation (Netatalk) of Apple Filing Protocol does support all the good stuff properly. Mainly:

• DHX2 (Diffie-Hellman Key Exchange 2) -based authentication: the old auth was plain-text, this is a huge improvement, all modern OS Xs have this as mandatory
  
• AFP Lock Stealing, + couple of other features: See Apple's requirements for Time Machine server
  

In my case, there is a HFS+ sparse file on an EXT4-partition. Setting this up with Time Machine is a breeze, however TM will "think" a while before mounting the sparse file and actually running the backup. There are a couple of user testimonials that occasionally (too often) TM will freeze and fail to do a backup. Also when the failure occurs, TM will fail to continue operation and a full backup media reset will be required.

The source of my information is QNAP wiki, which describes the process on old(ish) Mac OS X and Netatalk. I got my backup running based on that information. Also, if there are earlier reported failures to backup, I'll report back here.

The above setup sure is a bitch to get running. There is plenty of documentation and tools scattered around the Web, but it looks like the user funnel goes something like this:

• 1.000.000 users running Samba on their Linux
• 1.000 out of the above users are running OpenLDAP on their Linux(es)
• 1 out of the above users are running Samba with passdb backend = ldapsam

In the end, there is no definite document or tool to rely on. I spent about two weeks gathering information and trying out various approaches. I had to run my LDAP-queries unencrypted while sniffing the traffic with Wireshark to get an idea what kind of information is being requested.

In the end, just getting LDAP working on your server(s) is difficult enough for most people to get discouraged by the constant failures while attempting the setup. The advantages are there, being able to authenticate SSH-shell, secured web pages, WebDAV and any number of applications against exactly same user name / password -pair in a tested and secure manner is an execllent reward. Just having HTTP Basic Auth running against existing Linux userbase without LDAP is very difficult and mostly requires poking unnecessary holes to system security to get it running.

One of the really bad things is that not all documentations describes a simple step-by-step -process of making the setup secure. There is no need to allow all access to everybody, for example a simple:

olcAccess: {0}to attrs=userPassword,shadowLastChange
    by self write
    by anonymous auth
    by dn="cn=admin,dc=example,dc=org" write
    by * none

will make harvesting accidentally stored plain text -password much more difficult than the out-of-the-box solution does. All stored LDAP-passwords should be hashes, right? Not all tools default doing that.

When all the Samba-parts are in the LDAP, the above issue raises again. Using LanManager-passwords is out right stupid, they can be brute-forced with ease, but NTLM-passwords need to be protected with similar access-line:

olcAccess: {1}to attrs=sambaLMPassword,sambaNTPassword
    by dn.base="cn=admin,dc=example,dc=org" write
    by dn.base="cn=sambaservers,dc=example,dc=org" write
    by anonymous auth
    by self write
    by * none

After that, there is some sanity in system setup.

To get all the "Samba-parts" working into your LDAP, Microsoft Knowledgebase article Q243330 about Well-known security identifiers in Windows operating systems is a must-have reference. While debugging the LDAP-queries you will face something like this:

ldapsearch -x -b "dc=example,dc=org" \
"(&(&(objectclass=sambaGroupMapping)(sambaGroupType=4))
(|(|(|(|(|(|(|(|(|(sambaSIDList=S-1-1-0)(sambaSIDList=S-1-5-2))(sambaSIDList=S-1-5-11))
(sambaSIDList=S-1-22-2-1099))
(sambaSIDList=S-1-5-32-545))
(sambaSIDList=S-1-22-2-1101))
(sambaSIDList=S-1-22-2-1102))
(sambaSIDList=S-1-5-32-544)))))" cn gid

Initial impression will be WTF!? However, most of the SIDs are needed in your LDAP to make Windowses happy.

Some kind of setup wizard would be nice. It would save couple of weeks debugging / setup time.