[samv]

I worked out the solution to my question. The interface described below apply to Mac OS 10.5 Server (I expect Mac OS 10.5 Server will be similar but I haven’t yet had a chance to look at 10.6 Server).

To restored a Certificate Authority (CA) signed certificate it is important to backup at least two files:
mail.abt.com.au.[b]crt[/b] (Certificate)
mail.abt.com.au.[b]key[/b] (Private Key)

Two other files are not so critical for backup:
mail.abt.com.au.[b]crtkey[/b] (Certificate & Private Key)
mail.abt.com.au.[b]chcrt[/b] (Chained Certificate?)
mail.abt.com.au.[b]csr[/b] (Certificate Signing Request)

To import/restore a certificate (Certificate Authority signed certificate) in Server Admin:
1. Server Admin
2. Certificates
3. Import

[url]http://users.tpg.com.au/samven1/import_certificate.png[/url]

Certificate File > mail.abt.com.au.[b]crt[/b]
Private Key File > mail.abt.com.au.[b]key[/b]
Certificate Authority File > mail.abt.com.au.[b]crtkey[/b] or mail.abt.com.au.[b]chcrt[/b] or mail.abt.com.au.[b]crt[/b]

Enter ‘Private Key Passphrase’ if you elected to use a passphrase when you initially created your certificate (at self-signing stage).

Obviously, good IT administration dictates you backup your Certificate Authority (CA) signed certificates. Some CAs provide a re-issuing service. But this is the last thing you want to worry about if you have to rebuild a server in a hurry. All the best!

[samv]

It looks like a lot of people are having problems with AFP and Kerberos on Leopard Server. Apple forums have a lot of people reporting the same frustration.

[url]http://discussions.apple.com/forum.jspa?forumID=1233&start=0[/url]

I am also experiencing this problem.

My mail server is Open Directory Master. My file server is an Open Directory Replica. I am therefore using Kerberos. I don’t fiddle with any Kerberos configurations under the hood (ie beyond the GUI). For a while after booting the file server allows AFP connections. After a while (the period of time varies) all attempts to connect to the file server via AFP are refused citing incorrect username or password. Restarting AFP temporarily fixes the problem. It seems most people think the problem is related to Kerberos. Administrators are reporting that this problem persists after the Mac OS 10.5.2 Server update. Indeed, I can report the problem persists for me after upgrading to Mac OS 10.5.2 Server even if I apply the update immediately after Leopard Server installation.

I’ve been forced to revert to Mac OS 10.4 (Tiger) Server until I find a solution to this major headache.

Is anyone else experiencing this problem and does anyone have a solution?

Sam
Melbourne, Australia

[samv]

I had some success using a tip in another post here

I moved the mailbox to the /var/spool/imap/users directory using the mv command. Make sure the privileges (ownership and permissions) are correct on the folder. It is rather difficult changing folder and file permissions in the Finder (No read/write access to the /var/spool/imap/user folder in Finder).

I used chown to change the owner of the folder and files to ‘cyrusimap’:
sudo chown -R cyrusimap /var/spool/imap/user/mailboxname

I found the folder already belonged to the ‘mail’ group but you should check this:
sudo ls -la /var/spool/imap/user

Delete every file like “cyrus.*” in the mailbox.
sudo rm /var/spool/imap/user/mailboxname/cyrus.cache
sudo rm /var/spool/imap/user/mailboxname/cyrus.header
sudo rm /var/spool/imap/user/mailboxname/cyrus.index

Reconstruct a single mailbox with the following command:
sudo -u cyrusimap /usr/bin/cyrus/bin/reconstruct -r user/mailboxname

Or reconscrut all mailbox with the data:
sudo -u cyrusimap /usr/bin/cyrus/bin/reconscruct -r user/*

This restored the In Box (and the messages in the In Box). Woohooo! Unfortunately, this DID NOT restore IMAP folders and mail contained within. I wonder why? Does anyone have ideas?

The reconstruct command should probably be run with incoming and outgoing mail suspended first.

[samv]

The problem I had with Group Permissions seems to be fixed in the Mac OS 10.4.3 Server update.

[samv]

[QUOTE BY= macshome] I would use the new ACL propagation on 10.4 server, not the old umask based stuff for inherited permissions now.

And did you say that you have a special character in a path name? Bad admin! No admin cookie!

Josh[/QUOTE]

Hi Josh,

Great to meet you at WWDC 2005. Would a period/dot/fullstop and underscore be a bad character in an AFP and SMB share point path name? I read somewhere that the a space in a volume name is best avoided (however I’ve seen Mac OS 10.4 Servers with volume names containing a space character).

I thought periods in the path name would be OK. I’ll try removing all spaces and periods in the share point path name (tonight when staff aren’t using it).

Here is my share point path name (with just a couple of characters change to hide identity of company).

/Volumes/Xserve_RAID/Shared Items/mel.xyz.com.au/

Oh! And how are you using ACLs to supplant ‘inherit permissions’ behaviour? This sounds interesting.

[samv]

I too am having problems with Mac OS 10.4.2 Server not honouring ‘inherit permissions’ – it is driving me crazy. The GUI for setting ‘inherit vs POSIX’ was greyed out until I turned off ACL for my Xserve volume (an undocumented “feature” I came across after lots of hair pulling). I’ve checked that ‘inherit permissions’ is on for AFP and SMB at both the GUI interface and the command line interface (sudo sharing -l).

All my users are in the Open Directory LADP database. I have three Groups (also in the Open Directory LDAP database). I’ve tried setting noNetworkUsers to ‘yes’ (this didn’t make a difference for me – I wonder if it will disturb Retrospect).

Interestingly, AFP honours ‘inherit permissions’ on Share Points that reside on the boot volume however AFP doesn’t honour ‘inherit permissions’ on Share Points that reside on my Xserve RAID (it seems to be applying POSIX behaviour: read&write for owner, read-only for group and read-only for others). I wonder if there is something about the path (special character) that is causing the problem?

I’ve run Repair Disk on my Xserve RAID volume – no problems.

[samv]

[QUOTE BY= Guest] read the manual! it takes 3 seconds[/QUOTE]

Yeah, yeah. I got it working. It wasn’t clear in the manual that the Firewall had to be activated for NAT to work. Gimme a break, I tried quite a bit before posting the question. Others have also struggled with this so I thought an answer might have wider appeal. I’ve posted answers to basic questions so I feel I can post a ‘stupid’ question from time to time as long as it is clear and articulate.

[samv]

Thank you so much for the tip. Turning on the firewall fixed the problem – sharing my Internet connection on one Ethernet interface to a private network on another Ethernet interface via NAT is now working (at least for Macs on the LAN… I need to work out why the PC connection to the outside world isn’t working). I’m now well on the way to getting this working. I think all I have to do now is refine/finish setting up DHCP and firewall rules. Excellent!

[samv]

A permissions issue exists with Mac OS 10.x Public folders. A user who creates a new item (file or folder) owns the item and automatically has Read & Write privileges. Each Mac OS 10 user also belongs to a local group – other users in that Group gain Read & Write access to the file or folder. Others users (Everyone else) can’t modify or delete files/directories – they only have read access. Users who access the Public folder as Guest get Read Only access. In most situations this is what we want – it makes for a very secure operating system.

For our staff, wishing to share files and folders in a peer-to-peer manner, this not what we want applied to files and folders in the Public folder. Staff find they can’t modify or delete files in Public folders owned/created by someone else. To solve this problem I added the following job to the system (root) crontab file (/etc/crontab)

# Make files in Public folders read/write for all
*/1 * * * * root /bin/chmod -R a+rw /Users/*/Public
Note: Each space in the line above is actually a tab.

What does this do? Every minute, on the minute, this system (root) cron job makes all files and directories in users Public folder read/write for all (User, Group and Others).

Obviously this compromises the strong security provided in a standard Mac OS 10.3 installation. For most environments I believe this security is over zealous. One of the key features that made sharing files on earlier versions of the Mac OS (Mac OS 7, 8 and 9) is now a major headache. The average user will struggle with the the prermission issues in a standard Mac OS 10 setup. What I’d really like to see is a preference in the Sharing system preference/pane to provide read/write access to all files and directories in a users Public folder – much like a similar ‘inherit permissions’ feature available for Mac OS 10.3 Server share points.

(Aussie spelling)

[Author]

Posts