Smokes your problems, coughs fresh air.
Debian still uses the System V init scripts, which are very clumsy to use. Here are two Debian commands you might need often:
update-rc.d -f service remove
That will remove all the links in the runlevels to the script in init.d.
update-rc.d service defaults
That will make default start and stop links in all the runlevels.
I often get the “NameVirtualHost *:80 has no VirtualHosts” on my webservers. It seems that every version of every distro has different requirements. My existing Debian config was fine, until I upgraded to Lenny. With fiddling, I determined the solution:
In /etc/apache2/ports.conf, put (among other things):
NameVirtualHost * Listen 80 <IfModule mod_ssl.c> # SSL name based virtual hosts are not yet supported, therefore no # NameVirtualHost statement here Listen 443 </IfModule>
Then you can define virtual hosts:
<VirtualHost *>
ServerName bla
ServerAlias hoho
</VirtualHost>
The key is to not define *:80 for the namevirtualhost and virtual hosts. Instead, use the listen directive to define the port.
When you run virtual machines, the most convenient network setup is having a bridge between the virtual machine and your normal ethernet network. In Debian, I use the following config in /etc/network/interfaces to have such a bridge:
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface auto lo iface lo inet loopback # The first network card - this entry was created during the Debian installation # (network, broadcast and gateway are optional) auto eth1 iface eth1 inet manual auto br0 iface br0 inet static address 192.168.1.101 network 192.168.1.0 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.100 bridge_ports eth1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off
In this setup, the br0 gets the IP address that eth1 had before. Intuitively, I would have created a bridge which would connect eth1 and new interfaces, but when I did that, I could not get it to work.
I then used a command similar to this to install the virtual machine:
virt-install --connect qemu:///system -n vm10 -r 512 --vcpus=2 -f ~/vm10.qcow2 -s 12 -c ~/debian-500-amd64-netinst.iso --vnc --noautoconsole --os linux --os-variant debianLenny --accelerate --network=bridge:br0 --hvm
You can adjust where necessary. What’s important, is the –network=bridge:br0. This makes sure that kvm is run with:
kvm [more options] -net nic,macaddr=54:52:00:52:1c:7c,vlan=0,model=virtio -net tap,fd=7,script=,vlan=0,ifname=vnet0
The network setup looks like:
br0 Link encap:Ethernet HWaddr 00:15:17:23:83:67 inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe23:8367/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1866633 errors:0 dropped:0 overruns:0 frame:0 TX packets:1678602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:892540330 (851.1 MiB) TX bytes:971936093 (926.9 MiB) eth1 Link encap:Ethernet HWaddr 00:15:17:23:83:67 inet6 addr: fe80::215:17ff:fe23:8367/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13371212 errors:0 dropped:0 overruns:0 frame:0 TX packets:12703312 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4234365756 (3.9 GiB) TX bytes:201738186 (192.3 MiB) Memory:88180000-881a0000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2672817 errors:0 dropped:0 overruns:0 frame:0 TX packets:2672817 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:493599313 (470.7 MiB) TX bytes:493599313 (470.7 MiB) vnet0 Link encap:Ethernet HWaddr 00:ff:2d:a0:76:34 inet6 addr: fe80::2ff:2dff:fea0:7634/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:159072 errors:0 dropped:0 overruns:0 frame:0 TX packets:310906 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:10860687 (10.3 MiB) TX bytes:465526222 (443.9 MiB)
During my recent Gentoo update session, I was once again confronted with the inconvenience of not having my /etc/ directory under version management. This time, I thought I had the ideal SCM for this job: Git.
I found a blog post of a chap who has done the same. It includes a few notes I might not have thought about on my own and also a few very cool Debian tricks.
One of the steps that I might have overlooked myself is that it’s essential to make the .git directory group/world inaccessible with chmod go-rwx
. If I would have forgotten this, a smart attacker might use my Git repo to access forbidden file contents.
The author also describes a cool Post-Invoke for Debian’s dpkg that will automatically stage and commit configuration changes made by apt/dpkg (although, later, he mentions that Debian has gotten a package could etckeeper that does this automatically.
Now I would like to learn how I can let Gentoo’s etc-update do as much. In its /etc/dispatch-conf.conf I can only find the option to use (of all things) RCS to track replaced configuration files in a special directory (/etc/config-archive/ by default). Hopefully, there is some drop-in replacement for etc-update which does this and which can rid me of etc-update’s awkward interface at once.
A very common way to configure Exim on a Debian machine, is to make it a ‘satellite’; a server which uses another SMTP server for sending and does not do local delivery, the latter being the difference with a ‘smarthost’. It can be used by other computers in the network to send mail, but also by the machine itself, to send system notifications and such (one of my favorite apps, arpwatch, for example).
The following needs to be in /etc/update-exim4.conf:
dc_eximconfig_configtype='satellite' dc_other_hostnames='[mailname]' dc_local_interfaces='' dc_readhost='' dc_relay_domains='*' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='[your SMTP server]' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='false' dc_mailname_in_oh='true' dc_localdelivery='mail_spool'
The following needs to be in /etc/mailname:
[mailname]
[mailname] is the same in both locations, and is simply the FQDN (world wide, not just local, such as bla.net) which should appear after the @-sign. The reason that it must entered in both places, is because both have a different function. ‘etc/mailname’ Takes care of putting the specified domain after the @-sign if you mail to, for example, root. The ‘dc_other_hostnames’ is to let the server know that this is the machine that handles that domain. If you don’t specify the ‘dc_other_hostnames’, the server will just try to send it to the next relay. BTW, ‘dc_other_hostnames’ is colon (;) seperated.
Make sure the FQDN you use exists, otherwise a lot of mailservers refuse to accept it. What I don’t understand, though, is that in my experience, whatever you use as domain doesn’t have to exist as MX record, but just as an A record.
Also don’t forget to include an alias for root in /etc/aliases. I usually let all mail sent to root be sent to a local user, and alias that local user to an outside e-mail address.
© 2024 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments