launchd instructions for samba

[ylluminate]

It seems that it would be handy to have similar installation instructions that display after the installation / upgrade of samba like unto mysql, pgsql, redis, mongodb, etc. I found this gist that seems it would pretty much serve as the template for someone to get this into place from @maddox: https://gist.github.com/1938575

[maddox]

Just to save some time, beware that that was a work in progress and didn't exactly work 100%

But I'm def in favor of the proposal for more information like the MySQL formula.

On Aug 31, 2012, at 10:11 PM, George Plymale notifications@github.com wrote:

It seems that it would be handy to have similar installation instructions that display after the installation / upgrade of samba like unto mysql, pgsql, redis, mongodb, etc. I found this gist that seems it would pretty much serve as the template for someone to get this into place from @maddox: https://gist.github.com/1938575

— Reply to this email directly or view it on GitHub..

[ylluminate]

Do you have something that's working 100% now at this point? Additionally, you know, I was really disappointed with a reply I got back from the author of SMBUp. That little tool has some good potential. Essentially he has zero interest in a Hombrew modification to allow it to work with anything but the MacPorts pkg. Further, he feels that it's not worthwhile to facilitate a GUI for "advanced users." I certainly disagree and while I can configure samba myself from ground up (I've done it many times), I would much prefer a reliable gui that would help me get the job done a little quicker and that would remind me of options that I sometimes forget about, etc. Further, it could help to integrate more fully into the OS X experience. Frankly, the note nearly has me to the point of taking up the gauntlet and pounding out a stellar UI to help ameliorate the Apple deficiencies with their new crap smb solution.

[mxcl]

Anything we can do to help with the SMBup problems?

[ylluminate]

It doesn't really appear that there are unless we match the MacPorts config precisely. The developer really feels rather strongly about not supporting Homebrew, etc. I tried to convince him that programmatically it would NOT be exceptionally difficult to allow for other paths and to check the env for them, etc., but he shut down this idea with some degree of conviction. He further explained that (in his words) "90% of the tutorials out there point to Macports, so most users would have that if they had something already, and those that install through SMBUp would be able to follow further tutorials for hand-tweaking. The second is that macports install directories are uncommon enough to not be easily mistakable with other ways of installing software."

I had a slight degree of success when I linked /opt/local to /usr/local, however it starting having another odd crash after that that did not have a clear origin.

[mxcl]

I guess that's his prerogative, but I wonder how far you can go in life making software that isn't flexible.

Also, the stats I have suggest we overtook MacPorts in popularity ages ago.

[ylluminate]

Yeah, I hear ya. It was a discouraging email in that it just shows the direction this guy's plane is going. I suppose on the positive side it's a really good indication of a niche that needs to be filled.

[adamv]

Will accept a pull request that adds the caveats.

[eduo]

Hello. SMBUp developer here.

I feel my responses might lend themselves to be taken differently than I intended so I'll try to clarify a bit.

SMBUp was born, explicitly, as a way to avoid people having to follow the most common tutorials found when searching how to install Samba in Lion. All of these pointed at Macports.

The assumption was, and still is, that most "second tier" tutorials take for granted the installation carried out was from MacPorts and continue from there, assuming install directories and defaults.

SMBUp's raison d'être is to automate that specific installation so people following those tutorials can skip "steps 1 through 25" and just go on with the part that actually matters to them (configuring Samba once installed), avoiding installing macports and xcode to begin with.

So, if anything, I'm dead against users having to install MacPorts rather than in favour of it :) SMBUp installs Samba in the same way MacPorts would just as a convenience for these users.

Similarly, SMBUp assumes the users installing it either have zero knowledge or may have even botched a couple of past installations. This in turn means a lot of paths are hardcoded because there's no easy way to figure out what the "right path" might be. SMBUp must decide it's own path is the only one reliable in the system.

At its core SMBUp is designed explicitly for users that don't use package managers at all but just want to get Samba up and running without fuss.

In my original response to ylluminate (in a part not quoted) I tried to explain why I couldn't rely on "env" paths and variables, which can be condensed into "they're not reliable when dealing with users that might have tried to run every tutorial out there to get their stuff running and there's no way to distinguish them from knowledgeable users".

I have been thinking about adding an "advanced" section of settings that allows a user to define the paths for samba binaries and config files but the amount of error prevention I have to implement to deal with the unavoidable mangling of settings by entrepeneur users has meant I keep postponing both the functionality and the interface implementation of this.

STILL, using a different implementation of Samba is not hard. SMBUp only ever accesses the following binaries:

/opt/local/sbin/smbd (samba daemon) /opt/local/sbin/nmbd (netbios daemon) /opt/local/bin/testparm (config testing) /opt/local/bin/pdbedit (user management) /opt/local/bin/smbpasswd (password management)

And it writes to /opt/local/etc/samba3/smb.conf

All of the above can be mimicked with hardlinks (I don't expect symlinks would fail, but I'm rather fond of hardlinks).

As for "homebrew vs macports" for some reason macports keeps being the most "popular" package manager out there, if not in users at least in mindshare. I have no idea why but this is probably the reason most tutorials out there keep pointing at macports and not homebrew. I have tried both and you can even see me in some bugs related to samba here as well as there. I'm personally not married to either and sincerely wanted to make SMBUp something that doesn't depend on either (actually, considering SMBUp completely trashes Macports' installed packages since it outright replaces them, it's funny that I could be thought to be "favoring" them. I've been told I'm actively boycotting them).

Sorry for the long response. I hadn't seen this thread and I felt a bit of clarification was in order, as I felt my response and quote were taken out of context (without malice, obviously).

[thebodzio]

I didn't wanted to start a new issue, since I feel this is the right one, but I'm afraid it deviated much from the original subject and ended without clear conclusion or action. Yesterday I was compelled to install homebrew's samba on one of my machines. My intention was to replace Apple's smbd and netbiosd. I believe that to do it neatly and elegantly one should use “launchd way” for which plist files in /Library/LaunchDaemons are needed. I think it would be nice to have such files (or at least some info where to put them, some templates) in “one package” with the recipe. I also think maddox' org.samba.* files are a good start. I take a note about it being “work in progress”, but if one won't use them, one will end up using other, equally “work in progess” files, from some random blog post. The bottom line is: I'd love to see launchd files shipped with the samba recipe.

[eduo]

While a noble goal, keep in mind that to replace "elegantly" will always be an issue when the finder Sidebar is rendered useless for network shares when netbios from OS X is replaced by Samba's netbiosd. It might also break Network browsing and, from what I've heard, server mounting (although this last one doesn't make much sense).

Other than this, the launchd scripts are simple enough for starting and stopping. The "trick" in Apple's own is that one of them monitors changes to the network preferences and restarts the network sharing daemons when the file is modified. This could be done for Samba as well and then rolling the smbd and netbiosd into a single launchd (making netbiosd dependant of smbd, too). The problem would be that providing this much functionality would disconnect the user completely from the service installed, and mean they wouldn't know about the scripts at all to be able to troubleshoot it (and it's tremendously easy to break Samba when installed in Mountain Lion).

[thebodzio]

My experiences with “replacing sambas” are basically the same as yours—meaning: there are pros and cons. That's why I mentioned merely “shipping launchd files with recipe” (not a “full blown, all automatic installation” mind you). However, since I've read your reply, I think that also a description of the replacement process and a short list of known problems should find its way to INSTALL or README file, which should be “advertised” after install is finished. I agree the form of plist files here is quite simple, but I still believe it's much more convenient to have them already defined somewhere in the package and simply copy them to the right place, than to write them from scratch (especially if your—well… mine for that matter ;}—memory of specific syntax is a bit foggy). That's all. I think of it as of providing usable, sane defaults.

[eduo]

I use http://eduo.info/SMBUp/org.samba.smbd.plist and http://eduo.info/SMBUp/org.samba.nmbd.plist for SMBUp which seem to work for several thousand people. I believe they're the same as suggested but I wouldn't mind if they were used in a note as links for download. They could be shown in the installation of Samba for the user to get.

[MikeMcQuaid]

I'd sooner they were added as inline plists (or something similar) if that's ok.

[thebodzio]

@eduo Brilliant! :} @mikemcquaid I'd also like to see them inline, but having the links there too won't hurt for sure. Obviously parameter pointing to smb.conf location should be modified or even removed altogether if the user sticks to default homebrew location.