<html>
<body>
<br>
I am sorry Jay. I am a bit out of sorts as the Brits would put it.<br>
I just got back from a 4 day zip through London, Paris, Dusseldorf,<br>
and Milan, and back.&nbsp; My body does not know what time zone it
is<br>
in and my cognitive abilities are more like disabilities right now..
;-)<br><br>
<br>
If the game is all in the same partition, and you are using the same
executable<br>
you are golden. Just make sure they can execute it, and read
libraries,<br>
as well as NOT WRITE IT.<br><br>
There are many ways to allow the users to execute the executables.<br>
The user must have a way to either execute the executable as
&quot;admincliffy&quot;<br>
or you need to provide some other way to allow them to execute the
coduo_lnxded.<br><br>
One way is to allow the users to execute the file as if they were
&quot;admincliffy&quot;.<br><br>
(See http://catcode.com/teachmod/)<br><br>
ex:<br><br>
chmod u+s coduo_lnxded<br><br>
<br>
An alternate way is to set the groups the same for the users and the
executables,<br>
then the users can have their own account names.<br><br>
So for coduo_lnxded , this would be owned by admincliffy, and group
&quot;serveradmins&quot;.<br>
You want the users to be able to execute it, and access the link
libraries, bit NOT<br>
be able to change it.<br><br>
So the mode of the file&nbsp; should be -rwxr-x---.&nbsp; (Or mode:&nbsp;
750)<br><br>
(sidebar... to show you there are no ceilings here... easy stuff!
;-)<br><br>
rwxr-xr--&nbsp; = mode 754.&nbsp; Here is simply how it works.<br><br>
r = 4, w = 2, x = 1<br><br>
Why?&nbsp; Bit positions.. base 2 :&nbsp;&nbsp; 1, 2, 4, 8, 
etc.<br><br>
There are three types of permissions.&nbsp; USER, GROUP and OTHER (not
user or group).<br>
This is why there is 3 sets of rwx permissions.&nbsp; The left most are
the USER,<br>
the middle, GROUP, the last OTHER. (of everyone else..).<br><br>
so to set the mode as I stated above: -rwxr-x---<br><br>
You can either execute:<br><br>
chmod u+rwx coduo_lnxded<br>
chmod g+rx coduo_lnxded<br>
chmod o-rwx coduo_lnxded<br><br>
Or more easily: since you now know each, the OWNER, GROUP, and OTHER
are<br>
represented by r=4, w=2, x=1... You can simply do it all in
one...<br><br>
r+w+x = 4+2+1 = 7<br>
r+x = 4 + 1 = 5<br>
no r, no w, no x = 0<br><br>
mode 750<br><br>
hence:<br><br>
chmod 750 coduo_lnxded<br><br>
(see http://catcode.com/teachmod/) for a pretty decent tutorial.&nbsp;
But there is no magic,<br>
just Linux likes binary... so note in base 2:<br><br>
read bit = 4 = 100 binary<br>
write bit = 2 = 010 binary<br>
executable bit = 1 = 001 binary<br><br>
Note that a 7 (allow read, write and execute) is:&nbsp; 111.<br>
Or if you add:<br>
100 + (read)<br>
010 + (write)<br>
001 + (execute)<br>
-----<br>
111=&nbsp; or 7, (Read, plus Write, plus Execute)<br><br>
Nothing really fancy there at all!&nbsp; Easy to think of Read as 4,
Write as 2, and Execute as 1.<br>
Since I end up changing modes on files a lot, using the numbers become
very useful.<br><br>
Now if the linux executable files are GROUP &quot;serveradmins&quot;, and
lets say<br>
I am a customer, user name may be &quot;defilm&quot;, and group
&quot;serveradmins&quot;.<br>
The GROUP permissions would apply, and hence I would be able to<br>
Read and Execute files with group &quot;serveradmins&quot;, but NOT
WRITE<br>
them. (You don't want someone wiping your executable and killing
everyone's<br>
server).<br><br>
This is also safer IMHO than using a setuid and allowing users to
execute<br>
files as another user.<br><br>
You get all the benefits of the virtual Memory operating system,
same<br>
executables, and it still allows each user to have their own identity
and<br>
private files (for say... mods directories), and provides you with
total<br>
control over the master installation.<br><br>
I hope this helps.&nbsp; I could have left out the explanation and just
thrown in the<br>
commands like chmod u+rx filename, but I wanted to show you it is
only<br>
addition, and actually there is no magic, and it is actually easier to
use<br>
the numbers... (one command vs. 3...).&nbsp; No ceilings involved.
;-))<br><br>
If you need any additional info, please feel free to email me at
defilm@acm.org.<br>
I will be happy to help in any way.<br><br>
Happy Holidays,<br><br>
Mark<br><br>
Same post... Alt subject:<br><br>
ahhhhhhhhhhhhhhhhhhhhhhh!!!&nbsp; Where is the Linux 1.5.1 binaries??
Monday. Ok.<br>
But WHY? That is what worries me. :-(<br><br>
BTW... I have a wildly successful server at uo.team-ravage.com.&nbsp; It
runs Foy, all weapons<br>
wide open, 34 users, and is busy 24x7. (The US uses it, the UK uses
it).&nbsp; However, it<br>
is not fiscally reasonable for many of the admins on this list...&nbsp;
It is a Dual 3.2Ghz<br>
P4, 2 GB. (It also runs a rifles only server UO, which is often busy as
well).<br><br>
But it runs near 50-65% utilization. (Hello open tanks, jeeps and
n00bs...)<br>
This model does not bode well for virtual server utilization
obviously.&nbsp; I Just<br>
secured a duplicate server, and when I put uo 1.5.1 on there, I will make
a DNS<br>
change, flipping the server over to uo.team-ravage.com.&nbsp; I am
preying the CPU looks<br>
much better.<br><br>
I wanted to mention this because I wanted to be able to do a comparison.
So I have<br>
all the metrics from this server for the past 5 weeks of nearly 24x7
fullness.<br>
In fact, I did this server as a test ironically, after not being able to
tame this<br>
FOY beast, wide open, no matter how I played with Linux.&nbsp; My son
said &quot;Dad,<br>
you want a busy server, put up Foy, 24x7.&nbsp; The 13 y/o tike was
right! Filled up<br>
right away. Word spread, now it is used by the EU non-us hours, and US
most<br>
of the US time. (I have played on it, and I admit, it is kinda fun! Why
shoot someone<br>
with a MP44, when you can hit them with a flak canon? ;-)) (Actually some
of the<br>
central London side streets are kind of looking ratty like the scene, and
I was at<br>
the Ritz, on Buckingham Palace Drive while in London.&nbsp; Walk a few
blocks<br>
and up off center city... 4 blocks from the palace and those ally's
looked familiar,<br>
other than the ones in Foy don't have lots of little taverns, and the
walls on the buildings<br>
are in better condition in FOY. ;-)) (No offense to the Brits out there.
I love London, but it<br>
needs some fixin)<br><br>
I am hoping when I flip the DNS, they are all using the servername.<br>
Likely they added it to their favorites, and will lose it. But I have
stated<br>
spamming announcements accordingly. If they read them, they will be<br>
able to find the new 1.5.1...<br><br>
It will be an excellent test, as I have been monitoring that servers
full<br>
resources over the past 5 weeks.&nbsp; If the same people flip over, it
will<br>
really help see the difference on one of the most resource intensive
maps...<br><br>
I will report my findings back here of course.<br><br>
Happy Holidays to all.&nbsp; Nice job Ryan!&nbsp; Ya tha man!<br><br>
Dr. D<br><br>
At 05:25 PM 12/18/2004, Jay Vasallo wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Nice
explanation Dr. D. Unfortunately, I am still sweeping floors and not
painting ceiling as you are. </font><br>
&nbsp;<br>
<font face="arial" size=2>I have the game all loaded on the same
partition.</font><br>
&nbsp;<br>
<font face="arial" size=2>Main game is loaded at
<b>/games/cod-server/uo</b></font><br>
&nbsp;<br>
<font face="arial" size=2>USER's are loctaed at
<b>/home/user/cod-server/uo</b></font><br>
&nbsp;<br>
<font face="arial" size=2>I only have a single server.cfg in the
<b>/home/user/cod-server/uo/server.cfg</b></font><br>
&nbsp;<br>
<font face="arial" size=2>I point to <b>/games/cod-server</b> as my
executable directory because this is where the
</font><font face="arial" size=2 color="#808080">coduo_lnxded
</font><font face="arial" size=2>resides:</font><br>
<font face="arial" size=2>example:
<b>/games/cod-server/</font><font face="arial" size=2 color="#808080">coduo_lnxded</b></font><br>
&nbsp;<br>
<font face="arial" size=2>Now I make the <b>games/cod-server</b> owned by
admincliffy</font><br>
&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2>I get that far...But still unsure about this
linking process you are trying to explain. You say </font><br>
&nbsp;<br>
<font face="arial" size=2>&quot;</font><font face="Times New Roman, Times">
You should make the executable<br>
mode 0x750, and owned by the admin, group GID, so it is RWX by you the admin, <br>
while it is only readable and executable, but not writable by the Group of users with<br>
group GID. There is no need for it to be.&quot;</font><br>
&nbsp;<br>
<font face="Times New Roman, Times">I say headache and start hitting the books. Can you demonstrate how you would link the user to :</font><br>
<font face="Times New Roman, Times"><b>/games/cod-server</b> using this &quot;<b>mode 0x750</b>&quot; you refer to? </font><br>
&nbsp;<br>
<font face="arial" size=2>I would appreciate this. </font><br>
&nbsp;<br>
<font face="arial" size=2>=o)</font><br>
<font face="arial"><br>
</font>&nbsp;<br>
&nbsp;<br>
&nbsp;<br>

<dl>
<dd>----- Original Message ----- <br>

<dd>From:</b> <a href="mailto:defilm@acm.org">Mark J. DeFilippis</a> <br>

<dd>To:</b> <a href="mailto:cod@icculus.org">cod@icculus.org</a> ; <a href="mailto:cod@icculus.org">cod@icculus.org</a> <br>

<dd>Sent:</b> Saturday, December 18, 2004 3:58 PM<br>

<dd>Subject:</b> Re: [cod] Dr. D - This ones for you.<br><br>
<br>

<dd>Recently some updates were brought to my attention with<br>

<dd>regards to the sticky bit, and memory utilization (mbuf allocation),<br>

<dd>and I did a little research...<br><br>

<dd>The current writing referenced by many on this forum, is more semantics<br>

<dd>than anything else.&nbsp; Dating back prior to Unix V.3, Memory was very<br>

<dd>expensive. Hence, there was not often enough memory to keep all executable<br>

<dd>(text) pages in memory, and in severe cases, entire programs were swapped in<br>

<dd>and out, text pages were more often paged in and out as the CPU ran out of<br>

<dd>text to execute on behalf of a program.&nbsp; The CPU would request text code be<br>

<dd>read from swap, halt the program, put it on the I/O stack (waiting I/O), and move<br>

<dd>on to the next program for a set period of time, for CPU allocation.&nbsp; When the<br>

<dd>I/O was performed asynchronously, and the text copied in to memory, the program<br>

<dd>put in Wait I/O state&quot; was put in &quot;Runnable state&quot;.&nbsp; Cpu would then continue execution.<br><br>

<dd>As memory became cheaper, Unix systems were able to store more text pages<br>

<dd>in RAM, and in fact, you based your memory purchase on how large the applications<br>

<dd>were going to be for the user base. This way you could assure that all code could fit<br>

<dd>in memory, and hence Page swapping and Text page swapin, swapout was a No-No, and<br>

<dd>a execution killer. (Today, these swap variables still exist in vmstat, as it is not<br>

<dd>impossible to begin swapping text pages, and full page swapping is just not done.<br><br>

<dd>Today, with cheap ram, and faster disks, executable text is not even copied to SWAP<br>

<dd>anymore, since the executable code is made of two parts.. The local text portion of the<br>

<dd>code, and the shared link libraries reference.&nbsp; Between memory size, and buffer sizes<br>

<dd>entire application text pages are loaded.&nbsp; No more swapping, no more paging text pages,<br>

<dd>no more load from swap, so the sticky bit is irrelevant.<br><br>

<dd>In reality, this was really the case under systems as old as Unix V.3.2 as Unix moved<br>

<dd>to the Intel platform.&nbsp; When we designed applications, we made sure there was always<br>

<dd>enough ram. A paging program is a &quot;slow program&quot;.&nbsp; Gaming is much more sensitive<br>

<dd>as you know.<br><br>

<dd>Today, shared link libraries are loaded once. Your text code (The portion that is not<br>

<dd>global link library based) is loaded in to ram. However, please note, thing have not<br>

<dd>changed in relation to the memory usage for multiple copies of a program!<br><br>

<dd>If you load 7 copies of the executable, and the executables all have different<br>

<dd>inodes, Linux has no way of knowing any two executables are the same,<br>

<dd>hence it WILL load multiple copies in to ram. This can be seen.<br><br>

<dd>If you link them, they will all have the same inode value. Linux will load<br>

<dd>the code once using the same text pointers when executing. So there is<br>

<dd>still value in using links to the same inode when invoking the same program<br>

<dd>multiple times!<br><br>
<br>

<dd>In your specific case, I am assuming from the alternate path, that the executables<br>

<dd>are on one partition, and the users homes on another.&nbsp; If you link across file<br>

<dd>systems, of course Linux will make a copy, and all will have separate inode<br>

<dd>values, and you are SOL.&nbsp; This of course consumes more memory, and more disk.<br>

<dd>Likely no big deal on disk, but memory is still expensive to lease on servers!<br>

<dd>($50/mo from 1-2GB upgrade is a lot).<br><br>

<dd>If I were in your shoes, I would make a local copy of the executable owned by<br>

<dd>the admin name whatever it is (not hopefully root), and link it to each users<br>

<dd>directory.&nbsp; The users would be in the same GID.&nbsp; You should make the executable<br>

<dd>mode 0x750, and owned by the admin, group GID, so it is RWX by you the admin, <br>

<dd>while it is only readable and executable, but not writable by the Group of users with<br>

<dd>group GID. There is no need for it to be.<br><br>

<dd>You get to take advantage of the same inode value which is still more efficient in<br>

<dd>virtual machine based OS's today in it's memory utilization.. such as Linux.<br><br>

<dd>If you think about it, it really makes sense.&nbsp; Linux knows nothing from filenames.<br>

<dd>It knows Inode numbers (or index hash values in to the file descriptor block.<br>

<dd>Same inode, it knows is same file, same code text.&nbsp; Different inode, it knows<br>

<dd>nothing that the two programs running in memory are the same code...<br><br>

<dd>This is what I would do. I would expect largely many of the server admins do indeed<br>

<dd>have their virtual server hosting set up similarly when it comes to the COD executable...<br><br>

<dd>I hope this help.&nbsp; My thanks to those that pointed at the recent updates to mbuf()<br>

<dd>allocation via malloc(), and kernel references.<br><br>

<dd>Dr. D<br><br>
<br>

<dd>At 10:45 AM 12/17/2004, Jay Vasallo wrote:<br>
<blockquote type=cite class=cite cite>
<dd>OK, How do I do this usuing your method?<br><br>
<br>

<dd>----- Original Message ----- From: &quot;Jay Vasallo&quot; &lt;jayco1@charter.net&gt;<br>

<dd>To: &lt;cod@icculus.org&gt;<br>

<dd>Sent: Friday, December 17, 2004 9:30 AM<br>

<dd>Subject: [cod] Dr. D - This ones for you.<br><br>
<br>
<blockquote type=cite class=cite cite>
<dd>Dr. D Wrote:<br><br>

<dd>&quot;Because 10 servers your way will load 10 copies in to swap, 10<br>

<dd>copies in to memory, etc.&nbsp; Using the method of symlinks, which<br>

<dd>is really nothing more than a link in the super block.&nbsp; The super block<br>

<dd>maintains all information about which disk blocks belong tio which<br>

<dd>files.&nbsp; For your simlink the new file entry simply gets the same<br>

<dd>inode id copied to the table.&nbsp; Same inode, same code... With<br>

<dd>shared libraries in memory,&nbsp; for the 10 servers only 1 copy<br>

<dd>exists in swap. Only 1 copy exists in memory.<br><br>

<dd>I hope this is more clear.&quot;<br><br>

<dd>Dr. D<br><br>
<br>

<dd>Can you please explain this a little further:<br>

<dd>Lets say I have my games in:<br>

<dd>/games/cod-server/coduo_lxded<br>

<dd>and the useres at:<br>

<dd>/home/user/cod-server/uo<br><br>
<br>

<dd>How does help this help this situation.<br><br>

<dd>Thanks =o)<br>
<br>
</blockquote></blockquote></blockquote>
</dl><br>
(snip)<br><br>
<br><br>
<blockquote type=cite class=cite cite>
<dl>
<dd><tt>S1-------------------------------------------------------------------------------<br>

<dd>Mark J. DeFilippis, Ph. D EE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; defilm@acm.org<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; defilm@ieee.org<br><br>
</blockquote>
</dl>S2-------------------------------------------------------------------------------<br>
Mark J. DeFilippis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; defilm@acm.org<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; defilm@ieee.org<br><br>
<br>
</body>
</html>