Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old August 26, 2007, 10:49   #1
shadowsun
Rookie
 
Join Date: Aug 2007
Posts: 5
shadowsun is on a distinguished road
Multi-user *nix usability

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.
shadowsun is offline   Reply With Quote
Old August 26, 2007, 10:56   #2
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,947
Donated: $40
takkaria is on a distinguished road
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.
takkaria is offline   Reply With Quote
Old August 26, 2007, 11:08   #3
shadowsun
Rookie
 
Join Date: Aug 2007
Posts: 5
shadowsun is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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 is offline   Reply With Quote
Old August 26, 2007, 13:50   #4
shadowsun
Rookie
 
Join Date: Aug 2007
Posts: 5
shadowsun is on a distinguished road
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 is offline   Reply With Quote
Old August 26, 2007, 13:55   #5
shadowsun
Rookie
 
Join Date: Aug 2007
Posts: 5
shadowsun is on a distinguished road
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.
shadowsun is offline   Reply With Quote
Old September 2, 2007, 13:50   #6
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,947
Donated: $40
takkaria is on a distinguished road
How's this for new configure text?

Code:
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.
takkaria is offline   Reply With Quote
Old September 2, 2007, 13:56   #7
ajps
Apprentice
 
Join Date: May 2007
Location: Manchester, UK
Posts: 50
ajps is on a distinguished road
Quote:
Originally Posted by takkaria View Post
How's this for new configure text?

Code:
--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?
ajps is offline   Reply With Quote
Old September 7, 2007, 13:57   #8
shadowsun
Rookie
 
Join Date: Aug 2007
Posts: 5
shadowsun is on a distinguished road
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.
shadowsun is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.