Re: [cobalt-users] rag2 - Fixing Admin

[Diana Brake <diana@xxxxxxxxxxxxx>]

At 02:21 AM 7/27/2000 -0700, you wrote:
> So, has anyone found a simple way around the problem with user Admin only
> being able to handle 32 groups? (Is that correct?)
>
> Is there a simple way to indicate which groups you want it to handle?
>
> Is there a simple way to add yet another admin account such as admin2?
>
> I can't believe there's no simple way to have a username and password which
> can access your entire site via ftp. This is quite lame.
>
> Anyone have any thoughts on this? Hmmm, better keep them simple ;-)
>
> Scott
> --
> Scott Crumpton, Publisher                   Moriah Mountain Publishing
> mailto:scott@xxxxxxxxxx                         http://www.moriah.com/
>
> "With God, All Things Are Possible. Without God, Nothing Is Possible."

Hi Scott,

Here are some old instructions I wrote up several months ago. It really 
isn't hard or time consuming and doesn't break the GUI. I hope this helps

My Raq2's IP is not shared by any virtual site on the machine, and I don't 
use the Admin ID for anything but the maintenance of the Raq2. So, on the 
main Raq2 site, we set up multiple admins users, using the GUI interface 
..ex) Admin1, Admin2, Admin3, Admin4 etc. each admin can have his own 
unique name and password (they don't have to be called admin*). This puts 
the new admin users in the following lines in the /etc/group and note 
here..the /etc/group- files.

home:x:110:admin,admin2,admin3,admin4,admin5,
admin:x:27:admin,admin2,admin3,admin4,admin5

You have to add your admins after the original in the wheel by hand. (See 
note at bottom you may not want to do this)

wheel:x:10:root,admin,admin2,admin3,admin4,admin5

example of site# edited:

site11:x:122:admin
with:
site11:x:122:admin2


(I make backups of my group and group- files every time BEFORE editing 
them) (Note: you have to be root to edit the /etc/group file. After editing 
/etc/group, command: cp group group-  . This copies the group to the group- 
while retaining proper permissions for group-. I used to edit both these 
files separately then run "diff" just to make sure I got everything 
right...the cp is much faster and more accurate..*grin - thanks Jeff 
Lasman) (NOTE: if you use pico, use the -w switch when starting it. ex) 
pico -w is supposed to prevent line wrapping. I say this and note the fact 
that this doesn't work for me. The line starting:

site-adm:x:111:

had TONS of users in it and it wraps at least twice even with the -w. I 
have to make sure these lines are correct before closing the file. If you 
notice user IDs broken in the middle, place the cursor at the BEGINNING of 
the broken line and hit the backspace once, you'll see what I mean. Every 
user after the broken one will be denied access if this remains broken.)

I never use admin for a virtual site. He is only used for the maintenance 
of the Raq2. So admin2 was assigned sites 1-25, admin3 sites 26-50, admin4 
sites 51-75, etc. This makes it easy for me to remember which admin is used 
for a given site, and prevents the assigning of admin# to to many groups 
(the basis of this problem anyway..:). Creating a site through the GUI 
always places admin as a user in that group. So, I edit the group and 
group- files to take admin out and insert the appropriate admin# for each 
site. Because admin is not in lots of groups by default, my maintenance of 
these files does not have to be done on a daily or even weekly basis. Once 
set up, I find that I don't use the GUI interface for a given domain very 
often, because many of our clients like to do their own work, and most of 
my work is done through FTP just updating sites. You don't even have to 
update new sites right away unless you yourself are going to be 
administering/FTPing to them. Siteadmins are not affected by which of your 
own admins also has access..:)

So, the GUI still works...multiple admins are recognized, more sites can be 
added and my work gets done..:)

Diana
 Note about security that I've recently learned.

Every entry in your wheel group is allowed to su root. So, I removed the 
original admin from the wheel, the admin that shares the root password. I 
also removed all the admins that don't need to telnet. I placed one of my 
self-created admins there...one I hope no one else can guess, and that is 
the only one that can su root. This admin's password is different than 
root's so even if that admin was compromised, the bad guy would have to 
still spend time guessing root's password. This seemed easier and more 
secure than trying to change the fact that admin and root share a password. 
They still share..but admin can't su.  *grin. I know I'm repeating myself 
here, but I want to make it clear what I've done.
Crest Communications, Inc.		diana@xxxxxxxxxxxxx
Beautiful Sunny Florida		http://crestcommunications.com/
352-495-9359