From: Alexander C. <ale...@gm...> - 2011-11-19 23:29:30
|
On Sun, Nov 20, 2011 at 03:18, Kurtis Heimerl <khe...@cs...> wrote: > On Sat, Nov 19, 2011 at 3:09 PM, Alexander Chemeris > <ale...@gm...> wrote: >> On Sun, Nov 20, 2011 at 02:53, Kurtis Heimerl <khe...@cs...> wrote: >>> You need to run as root to install the configuration DBs anyhow, so >> >> Installation is different from running. > > I am aware of this. I'm saying that you'll install them with root > permissions, which you then have to change. This is just another command in the already long installation manual. Or, better - in an installation shell-script. >>> this lets us duck the permissions issues running as "not-root" would >>> create. >> >> To run OpenBTS you just need to give proper access rights to right >> directories. You may want to introduce a special user/group for >> OpenBTS, but that's not strictly required. All normal application do >> this :) Look as Asterisk, MySQL, Apache and 100500 of other *nix >> applications. OpenBTS is no different. "Don't run as root" is must for >> application to be considered seriously. > > You'll notice that those are all production services. Their default configuration is for testing only, as you may easily notice ;) >>> A lot of those would only manifest when trying to WRITE a >>> config variable... which would be a mess. >> >> That's another topic. We should put some effort and make error >> reporting in this case more user-friendly. > > It's a highly related topic. > >> >> Or at least document this on the wiki. >> >>> The install is NOT for 'production' boxes. Running as root is fine for >>> a desktop test bed. >> >> Running as root is never ok. >> I don't want OpenBTS or whatever other application to make something >> bad with my desktop system. > > Yes, running as root is ok if this is not a long-running service that > is used primarily for testing. You didn't get it. Running as root is not ok on any system. >> Btw, do you plan to have a manual for production boxes? > > I don't think this is a great use of my time, as the vast majority of > the people using OpenBTS are not doing in a production environment. > > However, I'm happy to let anyone who wants to document this process do > so. It's not rocket science, it's just unix permissions. > >> >>> Lastly, if I wanted to resolve this issue permanently, I'd put the >>> TMSI and Channel tables in /tmp instead of /var/run, as all users have >>> write access there to begin with and they are temporary files. >> >> This may be a solution. > > It would solve this small issue, but you still couldn't run OpenBTS as > root without a lot of monkeying. I mean, giving the user permission to > write to /var/run would work too. The idea here is to keep the install > simple, and this is totally tangential to that core problem. Btw, in our own test installations we place them in local directory and it works perfectly. Users usually have write access to a directory in which they have built OpenBTS :) -- Regards, Alexander Chemeris. |