Bugzilla – Bug 4718
HOME environment variable not available on SuSE with startproc; RPM installer doesn't work well on SuSE
Last modified: 2008-12-15 13:07:47 UTC
SuSE's "sysvinit" style startup scripts use an executable called "startproc" to change to the Slimserver userid and invoke Slimserver. During installation, if the user does not have a previous slimserver.conf file, Slimserver uses code in Prefs.pm to determine a default Cache directory by examining $ENV{'HOME'}. Startproc passes the current user's environment (i.e. "root") through to the new process. This means that even though the process is running under "slimserver", the value of $ENV{'HOME'} is still "/root". The further checks for existence of the cache directory and the writeability of the parent cause the cache directory to be undef'd, leaving it empty. This results in a permissions error trying to create "/MySQL" when setting up the MySQL instance. I have tested this on SuSE 9.1 and 10.1 and found the behavior to be the same on both. I was using the 1/28/2007 nightly build of 6.5. A summary of the problem and my investigation is also available at the above URL. Proposed solutions: a) Change the method of finding the user's home directory on Unix in Prefs.pm b) Warn users that this is an issue and have them set HOME to "/usr/local/slimserver" in the SuSE init scripts before calling startproc. The following code snippet can be used to determine the user's home directory using the password file on Unix systems without relying on the user's environment variables: @uvals = getpwuid($<); $dir = $uvals[7]; print ("Retreived home directory = ".$dir."\n");
AFAIK, slimserver does not ship with a Suse-compatible startup script. Are you referring to one of the startup scripts from the slimdevices wiki, or is this a Suse-created script from some official Suse repository. (I don't use Suse...) The init script in the slimserver RPM uses "daemon" which is a function that runs "runuser". This is the RH/Fedora way of doing things, but I'm not sure which other distros have this. FWIW, there are at least 3 different Suse startup scripts on the wiki. Some of them use startproc while at least one just uses su. What is the "proper" Suse method? Is it different between 9 and 10? In the short term, you may want to contribute a startup script to the wiki that really works based on your understanding of the problem.
Created attachment 1797 [details] SuSE 10.1 init.d skeleton Example init.d script for SuSE 10.1 and (it claims) for any LSB-compliant distro.
The script for 9.1 appears to be correctly coded in that it derives from the skeleton provided by SuSE for that release. The script for 9.3 appears to be a minimal script, probably based on other SuSE scripts. This is the one that uses su to invoke the Slimserver. It has a problem in that it won't work unless the Slimserver userid is set up for logins. The slimserver ID created by the RPM installation has logins disabled. This came up in a forum thread (http://forums.slimdevices.com/showthread.php?t=31727) and the answer was to modify the invocation slightly to use bash with su (however the 9.3 script in the Wiki doesn't have this modification). The 10.1 script also appears to be a very minimal script, perhaps based on a 9.x script of some kind. It certainly doesn't appear to look anything like the SuSE 10.1 skeleton, which I've attached for reference. SuSE 10 has two flavors of init.d skeleton: one specifically for SuSE and another that claims to be compatible with any distro based on the LSB as well as RedHat with or without LSB support. In any event, where a userid must be used with the invocation of a service (i.e. in those cases where the service itself doesn't have any setuid() code), startproc with a "-u" parameter is used on SuSE, which as noted also passes the current environment, rather than the new user's environment. I'm in the process of building a new server (provided NewEgg stops sitting on my new hard drive!) and will be installing SuSE 10.2 on it. In a week or two, when I get to the point of installing Slimserver, I'll check to see if anything has changed with regards to the environment behavior and I'll also take a look at making a startup script based on the LSB/compatible skeleton. While I don't mind contributing a new SuSE 10.x script, I'd really like to see Slimserver provided in a cross-distro RPM that worked for everyone. Supposedly, the above skeleton could be used as the basis for both LSB-compliant and RH/Fedora distros (i.e. it takes into account the fact that Fedora isn't LSB compatible by default). There's more info about the differences and how to handle them with a single script here: http://www.novell.com/coolsolutions/feature/11256.html Or, if it's too much work to make a single init script, perhaps the RPM could at least include a standard SuSE/LSB script would be helpful for those who aren't on Redhat (but do have LSB-compliant distros).
Created attachment 1808 [details] Working SUSE 10.2 init script This is a script I created after installing Slimserver on SUSE 10.2.
I performed a new installation of Slimserver on my new SUSE 10.2 system last night using the latest nightly build (SlimServer_6.5_v2007-02-05.noarch.rpm). After installation I took the SUSE skeleton script and modified it for Slimserver. I've attached that version to this bug report. The file should be put into /etc/init.d/slimserver and a symlink to it created as /usr/sbin/rcslimserver. Adding it to the runlevels for automatic starting and stopping is done with "insserv slimserver". It's interesting to note that after performing the customizations on the 10.2 skeleton, the resulting script was nearly identical in function to the 9.1 script posted in the Wiki. I didn't try it on the 10.2 system, but it appears that the 9.1 script would work with one minor modification (add "export HOME=..." just before invoking Slimserver). This script isn't cross-platform. I suppose I could set up Red Hat under VMware, but I wasn't that ambitious last night. :-) Feel free to post this script or do with it what you will. I'm also going to post my experiences to the forum for others in case it's helpful.
I'm no expert on rpm. What is the 'right' solution for this problem? Is there something we should add to the rpm package that would only be triggered under SuSE to set the right home directory?
I don't know, either. I don't know that much about RPM packaging to tell whether something like that is possible. Alternately, I've toyed with the idea of making a SUSE-specific RPM, but that's something that might take me several weeks to get to, given my time constraints. An alternative might be to include it in the RPM but renamed so that it won't interfere with anyone on another distribution (i.e. perhaps call in /etc/init.d/slimserver.SUSE). That would at least get a new SUSE user 90% of the way towards a complete install. There'd have to be some kind of information given at the end of the installation, though, to let the user know that on SUSE the automatic startup won't work. For example, when I installed the RPM I got the following messages: minilith:/data/system/Slimserver # rpm --install SlimServer_6.5_v2007-02-05.noarch.rpm slimserver: unknown service Point your web browser to http://minilith:9000/ to configure your server. minilith:/data/system/Slimserver # Perhaps it could be modified to point them to the Wiki entry for Linux installation (i.e. say something like "If you are using a Linux distribution other than Redhat, please consult the Wiki at (url) for more information about starting and configuring your Slimserver.").
I recently came across an interesting article at http://www.novell.com/coolsolutions/feature/11256.html regarding how to make init scripts and RPM scriptlets compatible between Fedora and SUSE. Interesting read. I'm not sure whether this is the best solution, or if it's better to have a build system that will provide different RPMs for different distros. For example, the (slowly moving) Fedora yum/RPM effort is very Fedora-centric because all of the dependencies are specific to certain Fedora repos due to naming conventions. I think it would be very difficult to make this work for multiple distros.
If the Redhat build is starting to diverge like that, then I'd agree that a separate RPM would be best. And given my experience last night installing on an AMD 64 system, I'm guessing you'll have to have separate ones for different architectures as well (I ran into the problem documented in bug 4615). I don't know what kind of SuSE install base you have though as to whether it's worth it for you to bother with a separate SuSE RPM. If not, I may take a shot at it, if for no other reason that it's annoying to have to deal with the problem every time I upgrade. From what I can tell at the moment, it appears that they'd be very similar (with only a small difference in where the script goes and how maybe in how the service is started).
I'll see if I can discover some hints here about what distros customers use, and I'll start an internal email thread to see if there's some kind of installer policy that I ought to also consider in setting the severity of this issue.
Updated the wiki to reflect this new script, thank you once again Aubrey. Adding myself as a CC, I'd like to hear as progress is (hopefully) made with the init script(s) in the RPM.
Fletch, do you think this is still an issue?
Yes. I know very little about SUSE, but I know that it's not easy to make RPMs that support both RH-derived OS's and SUSE. When I upload my changes (maybe later today), I plan to request feedback from the SUSE experts. I don't think I've made SUSE compatibility any worse (although I might have), but I certainly haven't made it any better. I suppose the long term options are: - Work with a SUSE expert to see if we can really make a universal RPM as per the Novell article cited in this bug discussion - SD agree to support a separate RPM for SUSE. I think one or more community members have already done this, but I haven't seen anything myself - Just make sure the wiki has updated instructions on the extra manual steps necessary to make the RPM work on SUSE
Created attachment 2310 [details] RPM supporting vanilla 'redhat' platform and openSUSE 10.3 So here are options 1 and 2. This is my cut at a specfile that builds pretty close to the redhat specfile in svn, and builds and installs in a relatively SUSE friendly manner - it needs slimserver.init and slimserver.config to be provided by the redhat+debian based makerelease.pl. Patch to that to follow...
Hi Will, Good timing. I'll take a closer look at your spec tomorrow and perhaps do some testing on CentOS. Please take a look at the new SqueezeCenter RPM I submitted today (see http://forums.slimdevices.com/showthread.php?t=39595). Hopefully we can figure out a way to collaborate on this. Frankly, I prefer option 2, but I'm sure SD doesn't...
(In reply to comment #15) > Good timing. I'll take a closer look at your spec tomorrow and perhaps do some > testing on CentOS. Please take a look at the new SqueezeCenter RPM I submitted > today (see http://forums.slimdevices.com/showthread.php?t=39595). Hopefully we > can figure out a way to collaborate on this. Frankly, I prefer option 2, but > I'm sure SD doesn't... I'd also consider building/hosting SqueezeCenter in the openSUSE build service, with the nice One Click Install frills, but I'm a bit concerned that the included binaries and any mp3 de/encoding capability may be a liability for us to distribute - the usual codecs PITA. I could possibly do a cleaned version and provide instructions on where to get the meat from, but this is a fiddle for users to deal with. The easiest option would be for me to provide a complete RPM, with opensuse repo metadata, and One Click YMP file, and get SD to distribute it on an as-is basis. That's a win/win, if SD can decouple support from distributing packages.
(In reply to comment #16) > I'd also consider building/hosting SqueezeCenter in the openSUSE build service, > with the nice One Click Install frills, but I'm a bit concerned that the > included binaries and any mp3 de/encoding capability may be a liability for us > to distribute - the usual codecs PITA. Not to mention the fact that you can't distribute the SD firmware and graphics anyway. > The easiest option would be for me to provide a > complete RPM, with opensuse repo metadata, and One Click YMP file, and get SD > to distribute it on an as-is basis. That's a win/win, if SD can decouple > support from distributing packages. After you look at my files, I'd be interested in your opinion as a SUSE expert on the feasibility of a universal RPM that works for both.
Will, I've been looking at your spec and reading some online docs. One unfortunate issue is that RH puts mysqld in a package called mysql-server while SUSE uses mysql. Do you have any thoughts on the best way to deal with this?
I think I've managed to build a SqueezeCenter RPM that works on both RH and SUSE. Please see http://forums.slimdevices.com/showthread.php?t=39595. Feedback from SUSE experts would be very welcome.
This is fixed in the new SqueezeCenter RPM which has a SUSE compatible init script. Please see http://forums.slimdevices.com/showthread.php?t=41217 and http://wiki.slimdevices.com/index.cgi?SqueezeCenterRPM for more information. Marking as FIXED.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.