[1999-10-31]
There are a million of these, but I thought I'd collect my own configuration here on the web so that I don't have to look all over for it when I need to do it again. I cannot even remember how many times I've forgotten some part of this and had to look it up again, wasting much time.
Note that I'm going to be brief and to the point. Some of these things may not be applicable to your distribution. I'm running debian on one box and SuSE on another (may go back to slackware on that one though), just so you know.
Never forget your friends at the Linux Documentation Project.
Some quick notes about setting up the basics of bash. Generally the first thing we want to do as Swedes is to get our national characters working. This is done by loading fi-latin1.map.gz, usually in one of the startup files (see /etc/rcS.d or /etc/rc.s) using the command /bin/loadkeys like so: /bin/loadkeys fi-latin1. The keymaps are stored in /usr/share/keymaps/i386/qwerty/.
Now, to get this working we need a couple of variables set. In your home (./~) create the file .inputrc and enter into it:
set convert-meta off
set output-meta on
set bell-style none
That last one is going to save you a lot of agony. More about configuring your keyboard can be read in the keyboard and Console HOWTO.
If you find these settings nice and working, then you probably want all users to recieve them by default, yes? Check if you have a directory called /etc/skel. Any files you put there will be copied to the home catalog of any users you create with adduser or useradd
There's this awesome HOWTO on this so I won't waste time writing my own. Just read it and follow the instructions. It's very simple, even I got it working on the first try ;-)
If you are at all like me you followed the instructions in the ip-masquerade-HOWTO a little too close and opened your box to the world. I'm assuming here that you used something like ipchains -A forward -s 192.168.1.0/24 -j MASQ to masquerade everything. Let's improve on this by filtering a couple of ports that noone on the internet need being able to connect to.
#!/bin/sh
echo "1" > /proc/sys/net/ipv4/ip_forward
ipchains -P forward DENY
ipchains -A input -i ppp+ -s 192.168.1.0/24 -l -j DENY
ipchains -A input -p tcp -i ppp+ -d 0/0 25 -j REJECT
ipchains -A input -p tcp -i ppp+ -d 0/0 137:139 -l -j DENY
ipchains -A input -p udp -i ppp+ -d 0/0 137:139 -l -j DENY
ipchains -A forward -s 192.168.1.0/24 -j MASQ
With rule number two we remove any weird spoofed packets we may encounter. -i ppp+ specifies any ppp interface. You are probably using ppp0, but this will work nicely. We are in fact saying that any incoming packet claiming to be from within our local network (192.168.* in my case) must be denied and logged (-l).
Since I'm not planning on sending or recieving any outside mail for the moment, I tell ipchains to reject any packets from the outside world destined for my SMTP service. REJECT differs from DENY in that REJECT will send an ICMP-packet to say the request was denied, whereas DENY will simply eat the incoming packet.
The next two lines are of a similar vein. They say that any incoming requests for a netbios/SMB connection shall be denied. I'm running samba, and I see no reason why the whole world should be able to connect to my shares, or even know that I am sharing smb resources. Here is the output of ipchains -L:
The script above was set up for easy editing of the rules. Now, since this configuration is stored in the kernel memory, we must see to it that it's restored on every reboot. I did this manually for some time, by simply calling the script above by hand when I were about to dial my ISP. However, there is a better way.
This explanation is pretty debian specific, but the concept is applicable to all distributions. I got this from the IP-Chains-HOWTO by the way, which is required reading if you want to secure your box. Anyway, what you do is this: Cut and paste the following script into /etc/init.d/packetfilter
Don't forget to set the the file permission to match the other files, chmod 755 packetfilter. Now create a link from /etc/rcS.d/S39packetfilter to the file above. Issue ln -s /etc/init.d/packetfilter /etc/rcS.d/S39packetfilter. The S39 makes sure that the rules are installed before the network interface goes up.
Now you should set up all the rules you want to use, then you issue /etc/init.d/packetfilter save to write these rules out to a file. What will happen at boot then is that a startup-file will automatically call your script with the parameter 'start', which restores the settings you wrote out with save. Tada!
This is a breeze, simply download the archive, unpack it and issue ./configure followed by make and finally make install. Then you will want to consult './docs/textdocs/UNIX_INSTALL.txt' for instructions on how to start samba with inetd. Just follow the dotted line and you will be fine. The big thing that remains after the basic installation is the configuration. I suggest you copy the file './examples/smb.conf.default' to '/usr/local/samba/lib/smb.conf' and then edit that file. I will now give you my configuration. First off I decided it was not worth the trouble to use encrypted passwords over the network. I have a small LAN that only I use (basically), so packet-sniffing is not an issue. Enabling plaintext passwords saves a lot of pain and suffering, but it is less secure. It's your call.
Anyway, Since I use Windows'98 I had to enable plaintext passwords. This is done by editing the registry like this:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP] "EnablePlainTextPassword"=dword:00000001
This entry does not normally exist, so you will have to add it yourself. Then it's time for my smb.conf. Remember, this one is not placed in /etc by default, but in /usr/local/samba/lib:
In the globals section you will probably want to change 'workgroup', and maybe 'security' too (man smb.conf for that). The rest is pretty self-explainatory, but you will probably have to look through the man-pages a little.
After this I could actually connect to the server and it's shares. Only problem was that I did not have write permission. Odd. Let's go into that...
Not really. Let me explain what I wanted to achieve and how I did it. This may not be the best way but it works, as far as I can see, exactly as I want it to. I'm currently dualbooting my BBS/Fileserver machine, running the fidonet mailer and BBS-software under Win'98, and the rebooting to use the box as a masquerading firewall when I want to connect to the internet. I'm currently shifting away from Win'98, but as long as the fidonet software under linux is mediocre (this is getting better) I will use this setup. Anyway, I'm running samba so that I can reach my FAT32 partitions over the LAN even when I boot into linux. My only problem was that I didn't get write permission to the shares. "Weird", I thought as I checked smb.conf to make sure "writeable = yes" was set for the shares. Then it dawned on me; samba is restricted by the rights of the user I'm connecting with at the mountpoint. You might find this obvious, but it's not mentioned in the documentation at all (I looked for it when the clueon fired). I thought samba (running as user root) would take care of this. Oh well, the usual "power of unix" thing I guess.
For a first fix I tried to chown and chmod the mountpoint, putting my own group for group, and giving group write-permission. This did not work. You see, the mount command will override the mountpoint permissions. This can be fixed by giving the wanted gid (group id) and umask to mount, like I do in my /etc/fstab
What happens is that I mount all my FAT32 partitions under /mnt, and two of them, dosc and dosf are chowned the group 'eddy' and the the permission 007. The permission mask is somewhat confusing, as it states which permissions are not set. In my case I give all rights to owner and group, giving other no rights at all. dosd and dose on the other hand are available for reading and listing to other.
Now root and users belonging to the group 'eddy' (which is just me, there won't be anyone else needing this in the near future so there's was no reason for me to create a dedicated group) will get read/write, while the rest will have no access. When I log in as 'eddy' on my Win'98 box and then connect to the linux share, I will in fact 'be' the user 'eddy' on the linux box, thereby being in the group 'eddy' and as such I am allowed access.
This concludes this nights adventures in the world of linux. Till next time, see ya'!
(c)1999 Eddy L O Jansson. All rights reserved. All trademarks acknowledged.