FTP On Lion Server

Much has been made about the demise of FTP on OS X Server. Well, while it may be badly burned, it’s not dead yet. Let’s look at enabling FTP first on the server and then per share. Enable FTP on the Server The first thing to do on a server that you want to expose through FTP is enable tnftpd. To do so, open Workgroup Manager or Server and create a group that has user who you want to provide FTP services to. In this example we are going to assume a dedicated FTP server and open access to everyone, but feel free to swap out your group name for the everyone group we use here. Once you have your group (everybody exists by default so we won’t need to create that one), use dseditgroup to create a group called com.aple.access_ftp (everything in this article requires sudo btw): dseditgroup -o create . com.apple.access_ftp By default the group is empty and so once enabled, no one will have access to the FTP service. So let’s add everybody: dseditgroup -o edit . -a everyone -t com.apple.access_ftp Now let’s fire up FTP using the ftp.plist Apple kindly left us in /System/Library/LaunchDaemons: launchctl load -w /System/Library/LaunchDaemons/ftp.plist Enable FTP on Shares By default share points in Lion have AFP and SMB enabled. The sharing command can be used to list and augment shares. To list: sharing -l Make note of the name for a share that you would like to enable FTP for, as well as whether AFP and SMB are enabled. Think of 3 boolean slots, with the first slot being AFP, the second FTP and the third SMB. Let’s use an example share of Seldon. Let’s also say AFP and SMB are enabled on Seldon by default. So sharing can be used to make a change (-e for edit) on the Seldon share, setting the services (-s) to 111: sharing -e Seldon -s 111 Or to enable just FTP (given that this example is a dedicated FTP server): sharing -e Seldon -s 010 And let’s say Seldon is a bit promiscuous and so we’re also going to enable guest for the FTP share: sharing -e Seldon -g 010 Finally, provide the permissions via chmod to grant or deny access at a file and folder level and you’re done. FTP on future shares can be enabled with two or three commands so FTP management really isn’t all that big a deal. Command line doesn’t always mean hard. In fact, some times it’s easier ’cause you’re not hunting around in nested screens for what to click on. Having said that, who knows if this is a temporary reprieve from Apple to finally get away from a protocol older than I am. We would all do well to switch to something more secure…

Making Every User an Admin

If you deploy a large number of computers to users who are somewhat likely to play practical jokes on each other then you will run into some interesting issues. If you are deploying one computer to every user and you want each user to be an administrator of their computer then you might be tempted to allow all users to be administrators of all computers. If you do then prepare for an infinite number of sometimes amusing practical jokes. But really, being proactive about this brings up an interesting point: how do you deploy a computer and make only the user who you want to be an administrator an administrator. In a large deployment of Mac OS X, you are going to likely have a map somewhere between what user has each computer. You may even go so far as to name the computers the same name that you name the user associated with the computer. If you do this, then you have a pretty straight-forward task ahead of you. Basically, you’ll add the user who you are handing the computer to an administrator by adding them to the admin group. In order to do so, can check the “Allow user to administer this computer” as you can see in the following figure. If you have a sizable deployment you’ll want to automate this task rather than log in as each user and set the setting. You can automate the task using the dscl command along with the append verb. For example to place the user cedge into the admin group:
sudo dscl . append /Groups/admin GroupMembership cedge
That works as a one-off operation but not in bulk. If your computer name is the same as the user who will be using the system you can then use the scutil command and “–get” the ComputerName:
scutil –get ComputerName
NOTE: The –get options in this article are two hyphens rather than one, WordPress just merges them for some reason… You can then use this as the variable to use for augmenting the GroupMembership for admin:
sudo dscl . append /Groups/admin GroupMembership `scutil —get ComputerName`
Pop that into a post-flight package and you’ve got yourself a solution where you make the primary user of a system the admin of the local box and then make the subsequent users standard accounts. If your ComputerName doesn’t match your user name then all is not lost. One way to grab what admin user you’d like for each host would be to populate something on the client with that information. Another would be to put it in a csv and read the line for the csv that is associated to the computer in to obtain it. If you populate something on the client it could be the Text1 field from Apple Remote Desktop. This can be done using the Remote Management option in the Sharing System Preference, clicking on Computer Settings and then typing the data into the Info 1: field. To insert the information at image time (or at least programmatically), you could use defaults to write it into com.apple.RemoteDesktop.plist, located in /Library/Preferences:
defaults write /Library/Preferences/com.apple.RemoteDesktop Text1 “cedge”
To then read that variable:
defaults read /Library/Preferences/com.apple.RemoteDesktop Text1
The command to set the admin user based on the Text1 field would then be:
sudo dscl . append /Groups/admin GroupMembership `defaults read /Library/Preferences/com.apple.RemoteDesktop Text1`
There are probably about as many other ways to go about this as there are Mac OS X mass deployments. For example, instead of inserting data into Text1 from a defaults command, you could use kickstart with the -computerinfo option to write data into -set1 -1 or something like that (which is likely safer than defaults, albeit more difficult if you decide to do it to your non-booted volume). But hopefully these options, somewhere down the road, will help someone (after all, that’s why we post this kind of thing, right?!?!).

More Group Management with dseditgroup

Now that we’ve covered using dscl to create a group, let’s look at using dseditgroup to do the same thing. In the previous example we created a group called Local Admins or ladmins for short. First let’s read that group’s information. To do so, run dseditgroup followed by the operation, which can be read, create, delete, edit or checkmember as the operations (verbs). The -o is optional, so :
dseditgroup -o read ladmins
Or the following has the same output:
dseditgroup read ladmins
In the case of a namespace collision between two ladmins in two directory services then the one listed highest in the Search Policy would be displayed. The
dseditgroup create -n /Local/Default -r “Local Admins2” ladmins2
Now read the group you just created and you’ll notice that it has a GeneratedUID and a PrimaryGroupID even though one was not specified. Let’s say you wanted to manually assign the PrimaryGroupID so you could hide a group; you could do so with a -i parameter and not that many want to you could also use the -g option to manually provide a GeneratedUID. Other parameters include -u and -P for placing the username and password into the command (ie – if you’re creating groups in LDAP), -a if you want to use the group name as a parameter rather than just trail the command with it, -n to define the Directory Domain node (ie – /LDAPv3/MYDOMAIN vs. /Local/Default vs. /var/Hidden), if you wanted to place keywords or comments then use the -k or -c respectively and encase them in doublequotes (“). I’m not in love with how you edit memberships, but here goes:
dseditgroup -o edit -n /Local/Default -a cedge -t user ladmins
In the above command we defined the node we were editing with the -n followed by the user we were adding to the group with the -a and then the -t for the type of object we’re adding into the group, which is listed last. The reason that you have to put the -t with user in there is because we could just as easily have said:
dseditgroup -o edit -n /Local/Default -a staff -t group ladmins
Which would have put a group called staff into the ladmins group (noted by the NestedGroups attribute). To verify membership, use the checkmember verb (insert witty Beavis and Butthead remark here;). If su’d the following command is likely to report back with the fact that no, root has not been added to the group; otherwise it will look at your currently logged in account:
dseditgroup -o checkmember ladmins
But you can check and see whether my account is a member of your ladmins group with the -m parameter on the command:
dseditgroup -o checkmember -m cedge ladmins
Now finally, since no one likes a messy Marvin, to delete our test group:
dseditgroup -o delete -n /LDAPv3/ldap.company.com -u myusername -P
mypassword extragroup
dseditgroup -o delete -n /Local/Default ladmins2