PDA

View Full Version : Multi-user *nix usability


shadowsun
August 26, 2007, 10:49
I see you've had a poll on if you should nuke multiuser code or not.

As somebody who runs a server that is used by multiple people, I simply have to recommend keeping the code.

I played Mines of Moria in highschool. I played the original rogue in college/university. I keep Angband installed on my multi-user servers and recommend people play it.

As such, I would like to point out that the --prefix option is not being honored by the makefile - it's explicitly declared in rules.mk that's included into the makefile itself. Without editing this, the game simply refuses to install as a multi-user platform.

You've no idea how happy I was to find an updated version of angband - and now I'm having to debork things in order to make it work.

It's not a question of "The package maintainer should this" or "The package maintainer should that" - It's a simple question of angband being compatible with the options that sysadmins/sysops/package maintainers/etc simply expect to function because it's a standard - such as --prefix.

There's not really any other game I know of that is not installable in a multi-user environment.

Here's what you should do, by the way things are usually done in my experiance:

First off, most of the people compiling angband are not package admins or sys admins. As such, it will be expected to use /usr/local as the default install path because it's a local-only package. A sysadmin will automatically override this with the --prefix directive, as will a package or distro maintainer - We install it into, say, /tmp/1348nbaliet5/usr/ tree, make sure the contents are layed out like they should be, check permissions, modify things if required, and build the package using /tmp/1348nbaliet5/ as the "base" directory. We then install the package.

Joe User running *nix on a private box will most likely never know, or care, where angband installs to - /usr/local/ is default for this reason. However, it is a de-facto standard that --prefix is supposed to be honored.

I'm currently debating if I should go through the trouble of locating all the hardcoded expectations with the values I *ought* to have been able to override, or if I shouldn't bother and simply use an older version of angband that supports the methodology in which I will use the game - or if I should leave V behind.

This does not make me a happy panda. I've been a sysadmin for more then a decade, and I was a systems operator for multi user machines for more then three years before that.

I'm absolutely more then happy to help out with bugtesting the installation features. However, as much as possible, I want to avoid having to write patches to *regress* multi-user support back into Angband.

Now for my last argument: This is part of Angbands *heritage* you're talking about nuking here. Making it single-user only will not only insure that it doesn't grow, it will provoke alot of people to say "Forget this, I've got 493 users with accounts on this system, I'm busy, and NetHack will give me the installation-set I need."

Please. Don't nuke the multi user environment code. Me & my users use this feature.

takkaria
August 26, 2007, 10:56
1. I know the autoconf support is broken; I need to fix it. It worked before, but I was trying to get it to behave like the old autoconf support worked wrt installing non-globally, and I broke it somehow. I'm not entirely sure what the old stuff did, and I'm not entirely what sure the new stuff does either, 'cos autoconf is a big mess. If you can tell me exactly what you expect to work, I can fix it based on those requirements, though you'll have to wait a while.

2. I won't be nuking the multiuser code.

shadowsun
August 26, 2007, 11:08
1. I know the autoconf support is broken; I need to fix it. It worked before, but I was trying to get it to behave like the old autoconf support worked wrt installing non-globally, and I broke it somehow. I'm not entirely sure what the old stuff did, and I'm not entirely what sure the new stuff does either, 'cos autoconf is a big mess. If you can tell me exactly what you expect to work, I can fix it based on those requirements, though you'll have to wait a while.

2. I won't be nuking the multiuser code.

Then you've got my support to the following tune:

I'm going to try and make it work on my system install wise, and then I'm going to tell you how I did it, and (if needed) toss you a patch. I don't have craploads of spare time; but this is one of the games that gets stuck on almost every box I maintain.

You just got my vote for president.

shadowsun
August 26, 2007, 13:50
Got it.

Here's the real problem: The makefiles are explicitly designed to refuse to do a systemwide install unless you pass --with-setgid to enable a group ID for the files. Once this option is passed, everything works just fine. If setegid value is null, none of the lib makefiles will to anything.

So for now, the "fix" is to just toss --with-setgid to it. Note, this forces the arch independent data into $prefix/share/$package (or /usr/games/share/angband as I was doing it) which is absolutely fine. However, apex, bone, data and save directories are rwx to this group.

Apex is required (highscores file.) However, I'm not sure off the top of my head what the rest do - it's been a long time since I've mucked with this.

In data, spells.raw ended up being owned by a player since that player was the first one to run the game...

Looks like there's some fixing up to do. But, all you have to do to make the game install without --with-setgid is to add else clauses to the if ${SETEGID} != x segments in those makefiles.

hopefully this makes your world a little bit easier.

shadowsun
August 26, 2007, 13:55
Oh - and here's the chunk of configure.ac I actually did change:


AC_ARG_WITH(setgid, [ --with-setgid=NAME install angband as group NAME -
required for multiuser.])
AC_ARG_WITH(libpath, [ --with-libpath=PATH use PATH as the path to the Angb
and lib folder])

if test "$with_libpath" != ""; then
libpath="${with_libpath}"
elif test "$with_setgid" != ""; then
libpath="${prefix}/share/${PACKAGE}/"
else
libpath="${prefix}/share/${PACKAGE}"
bindir="${prefix}/bin/"
fi

----

addendum:
the reason spell.raw becomes owned by the first person who plays it is because it's not created by the Makefile - edit lib/data/Makefile and add in touch ${DATA_PATH}/data/spell.raw

Mostly this has just been horribly neglected. How long was it mostly unmaintained before you picked it up? My internal timeline has a gap of several years.

takkaria
September 2, 2007, 13:50
How's this for new configure text?

Please run ./configure with one of:

--with-setgid=<groupname>
This configures the game to store savefiles and scorefiles in a central
location on the system, writeable only by the group "groupname". If you
want a traditional installation of Angband, where all users share a
scorefile, then use this option, and set the groupname to your "games"
group. This option requires the game to have the "setgid" bit set on its
permissions, and thus this option requires root when installing.

--with-private-dirs
This configures the game to store savefiles and scorefiles for each user
in that user's home directory. The game requires no special privileges if
you do this, and should be used for most installations of the game.

--with-noinstall
This configures the game to store savefiles and scorefiles in the "lib"
directory that the game uses. This is useful if you don't want to install
system-wide at all; "make install" will just move the executable to the
directory below "src" if you choose this option.

ajps
September 2, 2007, 13:56
How's this for new configure text?


--with-noinstall
This configures the game to store savefiles and scorefiles in the "lib"
directory that the game uses. This is useful if you don't want to install
system-wide at all; "make install" will just move the executable to the
directory below "src" if you choose this option.


Directory above "src", surely?

shadowsun
September 7, 2007, 13:57
That's absolutely wonderful - In fact, it's damn near perfect.

Thank you, and I'll continue to help where I see a place I'll be useful and I don't have real life trying to swamp me.

Oddly enough, working helldesk is more stressful then being just a unix sysadmin. Maybe it's all the people... lol. ;)