Buck wrote:
I think that idea is most unwise. What will happen if you die suddenly? Or travel somewhere and are stuck there (...or any number of other life situations...) and there is an emergency at the office involving your server? If you keep such a tight policy on a server such that there is no one else who knows how to rescue the machines or get at them, you will look really bad and have a lot of explaining to do.1) Prevent users from logging in at the keyboard of the server. The users buck, root and net manager will need permission to log from the keyboard but I don't want ANYONE in the company to have access to the server directly from the keyboard.
You really must train at least 3-4 other people in how to use the machine you set up. And give them the root password.
Removing the keyboard and mouse and locking the box into a cabinet is not a security solution, anyhow, as it is possible to ssh login into the machine remotely. This is called a headless machine. Set up the 3-4 trainees with public key ssh access to the server so they can administer it. But they still need complete physical access in case a drive crashes or some other unexpected thing happens.
2) Each user's private directory has Linux OS (I guess) related files. Since they won't be using Linux, I would like to either delete them or create empty directories like the groups create.
You mean the home directories? Why bother "cleaning them up"? There is no percentage in it. When you think about it, you don't want to waste the time writing scripts that you don't know how to code yet and then running them at great risk of creating a mess.
3) Somewhere in the mix I setup a public directory. Users have browse access and nothing else. I think I know how to remove it though.
4) I have a folder and account setup called pcguest. "bad-user" defaults to that folder but has not access in it. I am wondering if I can remove that account and folder as I see no need to have guest accounts at this time. Guest accounts need to be on the workstations and guests have no reason to access my server, at least not in the business model I am using.
You might want to read the Samba book published by O'Reilly.
5) What am I not thinking of?
I have learned that initially setting up Linux as a firewall is a PITA, lots of work, I can save the necessary config files to make next time quick and easy.
The book Linux Firewalls by Robert Ziegler can help you a lot, if you are truly running a firewall (a machine dedicated to filtering incoming ethernet packets to help prevent network-based intrusion attempts) instead of a file server (a machine that stores files for some purpose.)
It looks like I have to modify the samba.conf for each group I add, but
adding users is very easy.
I downloaded samba-2.2.8a-2rh9.i386.rpm from Samba.org. I read that 3.x
does not include SWAT (which I like). Earlier on a previous install I
tried updating to 3.x but the system still shows 2.x being used. I
don't know if it is important that I upgrade or not. I don't care as
long as the version I am using will work safely and reliably. It might
be that SWAT isn't compatible, I don't know. I didn't try to install
3.x on this system. I'll leave it up to those of you with more
experience to let me know if it is something I need or not.
When I installed RHL 9, it installed Samba and when I installed the
Samba 2.x that I downloaded, it appeared to have uninstalled the
previous version.
Once the dust settles on the four items listed above, I will want to add backup and security. Once those are completed, I will have my dedicated file server and will select feature to learn.
Thank you all for your help.
Buck
-- Bob Cochran Greenbelt, Maryland, USA http://greenbeltcomputer.biz/
-- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
