[cod] Dr. D - This ones for you.
Mark J. DeFilippis
defilm at acm.org
Sun Dec 19 11:18:27 EST 2004
I am sorry Jay. I am a bit out of sorts as the Brits would put it.
I just got back from a 4 day zip through London, Paris, Dusseldorf,
and Milan, and back. My body does not know what time zone it is
in and my cognitive abilities are more like disabilities right now.. ;-)
If the game is all in the same partition, and you are using the same executable
you are golden. Just make sure they can execute it, and read libraries,
as well as NOT WRITE IT.
There are many ways to allow the users to execute the executables.
The user must have a way to either execute the executable as "admincliffy"
or you need to provide some other way to allow them to execute the
coduo_lnxded.
One way is to allow the users to execute the file as if they were
"admincliffy".
(See http://catcode.com/teachmod/)
ex:
chmod u+s coduo_lnxded
An alternate way is to set the groups the same for the users and the
executables,
then the users can have their own account names.
So for coduo_lnxded , this would be owned by admincliffy, and group
"serveradmins".
You want the users to be able to execute it, and access the link libraries,
bit NOT
be able to change it.
So the mode of the file should be -rwxr-x---. (Or mode: 750)
(sidebar... to show you there are no ceilings here... easy stuff! ;-)
rwxr-xr-- = mode 754. Here is simply how it works.
r = 4, w = 2, x = 1
Why? Bit positions.. base 2 : 1, 2, 4, 8, etc.
There are three types of permissions. USER, GROUP and OTHER (not user or
group).
This is why there is 3 sets of rwx permissions. The left most are the USER,
the middle, GROUP, the last OTHER. (of everyone else..).
so to set the mode as I stated above: -rwxr-x---
You can either execute:
chmod u+rwx coduo_lnxded
chmod g+rx coduo_lnxded
chmod o-rwx coduo_lnxded
Or more easily: since you now know each, the OWNER, GROUP, and OTHER are
represented by r=4, w=2, x=1... You can simply do it all in one...
r+w+x = 4+2+1 = 7
r+x = 4 + 1 = 5
no r, no w, no x = 0
mode 750
hence:
chmod 750 coduo_lnxded
(see http://catcode.com/teachmod/) for a pretty decent tutorial. But there
is no magic,
just Linux likes binary... so note in base 2:
read bit = 4 = 100 binary
write bit = 2 = 010 binary
executable bit = 1 = 001 binary
Note that a 7 (allow read, write and execute) is: 111.
Or if you add:
100 + (read)
010 + (write)
001 + (execute)
-----
111= or 7, (Read, plus Write, plus Execute)
Nothing really fancy there at all! Easy to think of Read as 4, Write as 2,
and Execute as 1.
Since I end up changing modes on files a lot, using the numbers become very
useful.
Now if the linux executable files are GROUP "serveradmins", and lets say
I am a customer, user name may be "defilm", and group "serveradmins".
The GROUP permissions would apply, and hence I would be able to
Read and Execute files with group "serveradmins", but NOT WRITE
them. (You don't want someone wiping your executable and killing everyone's
server).
This is also safer IMHO than using a setuid and allowing users to execute
files as another user.
You get all the benefits of the virtual Memory operating system, same
executables, and it still allows each user to have their own identity and
private files (for say... mods directories), and provides you with total
control over the master installation.
I hope this helps. I could have left out the explanation and just thrown
in the
commands like chmod u+rx filename, but I wanted to show you it is only
addition, and actually there is no magic, and it is actually easier to use
the numbers... (one command vs. 3...). No ceilings involved. ;-))
If you need any additional info, please feel free to email me at
defilm at acm.org.
I will be happy to help in any way.
Happy Holidays,
Mark
Same post... Alt subject:
ahhhhhhhhhhhhhhhhhhhhhhh!!! Where is the Linux 1.5.1 binaries?? Monday. Ok.
But WHY? That is what worries me. :-(
BTW... I have a wildly successful server at uo.team-ravage.com. It runs
Foy, all weapons
wide open, 34 users, and is busy 24x7. (The US uses it, the UK uses
it). However, it
is not fiscally reasonable for many of the admins on this list... It is a
Dual 3.2Ghz
P4, 2 GB. (It also runs a rifles only server UO, which is often busy as well).
But it runs near 50-65% utilization. (Hello open tanks, jeeps and n00bs...)
This model does not bode well for virtual server utilization obviously. I Just
secured a duplicate server, and when I put uo 1.5.1 on there, I will make a DNS
change, flipping the server over to uo.team-ravage.com. I am preying the
CPU looks
much better.
I wanted to mention this because I wanted to be able to do a comparison. So
I have
all the metrics from this server for the past 5 weeks of nearly 24x7 fullness.
In fact, I did this server as a test ironically, after not being able to
tame this
FOY beast, wide open, no matter how I played with Linux. My son said "Dad,
you want a busy server, put up Foy, 24x7. The 13 y/o tike was right! Filled up
right away. Word spread, now it is used by the EU non-us hours, and US most
of the US time. (I have played on it, and I admit, it is kinda fun! Why
shoot someone
with a MP44, when you can hit them with a flak canon? ;-)) (Actually some
of the
central London side streets are kind of looking ratty like the scene, and I
was at
the Ritz, on Buckingham Palace Drive while in London. Walk a few blocks
and up off center city... 4 blocks from the palace and those ally's looked
familiar,
other than the ones in Foy don't have lots of little taverns, and the walls
on the buildings
are in better condition in FOY. ;-)) (No offense to the Brits out there. I
love London, but it
needs some fixin)
I am hoping when I flip the DNS, they are all using the servername.
Likely they added it to their favorites, and will lose it. But I have stated
spamming announcements accordingly. If they read them, they will be
able to find the new 1.5.1...
It will be an excellent test, as I have been monitoring that servers full
resources over the past 5 weeks. If the same people flip over, it will
really help see the difference on one of the most resource intensive maps...
I will report my findings back here of course.
Happy Holidays to all. Nice job Ryan! Ya tha man!
Dr. D
At 05:25 PM 12/18/2004, Jay Vasallo wrote:
>Nice explanation Dr. D. Unfortunately, I am still sweeping floors and not
>painting ceiling as you are.
>
>I have the game all loaded on the same partition.
>
>Main game is loaded at /games/cod-server/uo
>
>USER's are loctaed at /home/user/cod-server/uo
>
>I only have a single server.cfg in the /home/user/cod-server/uo/server.cfg
>
>I point to /games/cod-server as my executable directory because this is
>where the coduo_lnxded resides:
>example: /games/cod-server/coduo_lnxded
>
>Now I make the games/cod-server owned by admincliffy
>
>
>I get that far...But still unsure about this linking process you are
>trying to explain. You say
>
>" You should make the executable
>mode 0x750, and owned by the admin, group GID, so it is RWX by you the admin,
>while it is only readable and executable, but not writable by the Group of
>users with
>group GID. There is no need for it to be."
>
>I say headache and start hitting the books. Can you demonstrate how you
>would link the user to :
>/games/cod-server using this "mode 0x750" you refer to?
>
>I would appreciate this.
>
>=o)
>
>
>
>
>----- Original Message -----
>From: <mailto:defilm at acm.org>Mark J. DeFilippis
>To: <mailto:cod at icculus.org>cod at icculus.org ;
><mailto:cod at icculus.org>cod at icculus.org
>Sent: Saturday, December 18, 2004 3:58 PM
>Subject: Re: [cod] Dr. D - This ones for you.
>
>
>Recently some updates were brought to my attention with
>regards to the sticky bit, and memory utilization (mbuf allocation),
>and I did a little research...
>
>The current writing referenced by many on this forum, is more semantics
>than anything else. Dating back prior to Unix V.3, Memory was very
>expensive. Hence, there was not often enough memory to keep all executable
>(text) pages in memory, and in severe cases, entire programs were swapped in
>and out, text pages were more often paged in and out as the CPU ran out of
>text to execute on behalf of a program. The CPU would request text code be
>read from swap, halt the program, put it on the I/O stack (waiting I/O),
>and move
>on to the next program for a set period of time, for CPU allocation. When the
>I/O was performed asynchronously, and the text copied in to memory, the
>program
>put in Wait I/O state" was put in "Runnable state". Cpu would then
>continue execution.
>
>As memory became cheaper, Unix systems were able to store more text pages
>in RAM, and in fact, you based your memory purchase on how large the
>applications
>were going to be for the user base. This way you could assure that all
>code could fit
>in memory, and hence Page swapping and Text page swapin, swapout was a
>No-No, and
>a execution killer. (Today, these swap variables still exist in vmstat, as
>it is not
>impossible to begin swapping text pages, and full page swapping is just
>not done.
>
>Today, with cheap ram, and faster disks, executable text is not even
>copied to SWAP
>anymore, since the executable code is made of two parts.. The local text
>portion of the
>code, and the shared link libraries reference. Between memory size, and
>buffer sizes
>entire application text pages are loaded. No more swapping, no more
>paging text pages,
>no more load from swap, so the sticky bit is irrelevant.
>
>In reality, this was really the case under systems as old as Unix V.3.2 as
>Unix moved
>to the Intel platform. When we designed applications, we made sure there
>was always
>enough ram. A paging program is a "slow program". Gaming is much more
>sensitive
>as you know.
>
>Today, shared link libraries are loaded once. Your text code (The portion
>that is not
>global link library based) is loaded in to ram. However, please note,
>thing have not
>changed in relation to the memory usage for multiple copies of a program!
>
>If you load 7 copies of the executable, and the executables all have different
>inodes, Linux has no way of knowing any two executables are the same,
>hence it WILL load multiple copies in to ram. This can be seen.
>
>If you link them, they will all have the same inode value. Linux will load
>the code once using the same text pointers when executing. So there is
>still value in using links to the same inode when invoking the same program
>multiple times!
>
>
>In your specific case, I am assuming from the alternate path, that the
>executables
>are on one partition, and the users homes on another. If you link across file
>systems, of course Linux will make a copy, and all will have separate inode
>values, and you are SOL. This of course consumes more memory, and more disk.
>Likely no big deal on disk, but memory is still expensive to lease on servers!
>($50/mo from 1-2GB upgrade is a lot).
>
>If I were in your shoes, I would make a local copy of the executable owned by
>the admin name whatever it is (not hopefully root), and link it to each users
>directory. The users would be in the same GID. You should make the
>executable
>mode 0x750, and owned by the admin, group GID, so it is RWX by you the admin,
>while it is only readable and executable, but not writable by the Group of
>users with
>group GID. There is no need for it to be.
>
>You get to take advantage of the same inode value which is still more
>efficient in
>virtual machine based OS's today in it's memory utilization.. such as Linux.
>
>If you think about it, it really makes sense. Linux knows nothing from
>filenames.
>It knows Inode numbers (or index hash values in to the file descriptor block.
>Same inode, it knows is same file, same code text. Different inode, it knows
>nothing that the two programs running in memory are the same code...
>
>This is what I would do. I would expect largely many of the server admins
>do indeed
>have their virtual server hosting set up similarly when it comes to the
>COD executable...
>
>I hope this help. My thanks to those that pointed at the recent updates
>to mbuf()
>allocation via malloc(), and kernel references.
>
>Dr. D
>
>
>At 10:45 AM 12/17/2004, Jay Vasallo wrote:
>>OK, How do I do this usuing your method?
>>
>>
>>----- Original Message ----- From: "Jay Vasallo" <jayco1 at charter.net>
>>To: <cod at icculus.org>
>>Sent: Friday, December 17, 2004 9:30 AM
>>Subject: [cod] Dr. D - This ones for you.
>>
>>
>>>Dr. D Wrote:
>>>
>>>"Because 10 servers your way will load 10 copies in to swap, 10
>>>copies in to memory, etc. Using the method of symlinks, which
>>>is really nothing more than a link in the super block. The super block
>>>maintains all information about which disk blocks belong tio which
>>>files. For your simlink the new file entry simply gets the same
>>>inode id copied to the table. Same inode, same code... With
>>>shared libraries in memory, for the 10 servers only 1 copy
>>>exists in swap. Only 1 copy exists in memory.
>>>
>>>I hope this is more clear."
>>>
>>>Dr. D
>>>
>>>
>>>Can you please explain this a little further:
>>>Lets say I have my games in:
>>>/games/cod-server/coduo_lxded
>>>and the useres at:
>>>/home/user/cod-server/uo
>>>
>>>
>>>How does help this help this situation.
>>>
>>>Thanks =o)
>>>
(snip)
>S1-------------------------------------------------------------------------------
>Mark J. DeFilippis, Ph. D EE defilm at acm.org
> defilm at ieee.org
>
S2-------------------------------------------------------------------------------
Mark J. DeFilippis defilm at acm.org
defilm at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20041219/f2ce053b/attachment.htm>
More information about the Cod
mailing list