If you find one of your servers with the ugly directory listing enabled, there’s a quick way to disable it in Debian
# echo autoindex | a2dismod
# /etc/init.d/apache2 restart
For other Apache installations in other distro, you can simple find the Autoindex option in your config file and delete it manually, then restart Apache
EDIT: a cleaner and more elegant way to achieve the same is, as the comments section says
# a2dismod autoindex
thanks :)
If you are managing a remote Linux network and you are tired of NATting or two ssh hops to enter a remote server, but OpenVPN poses too much overhead, you can use ssh tunneling to easily create a workstation-to-site VPN.
I’ve tested this with Ubuntu 9.10 Karmic Koala as the workstation and Debian 5.0 Lenny as the server, but it should work identically with older Ubuntu and Debian (both server or workstation).
I’ve been inspired by these two tutorials, although both didn’t work 100% for me, but joining pieces did the trick, so here I am :)
Software prerequisites:
Network configuration (as an example)
First of all, on the workstation generate a dedicated key (it should be a dedicated one cause the server will identify you’re going to bring up a tunnel based on the key you’re using to connect) with
# ssh-keygen -f /root/.ssh/VPNkey -b 2048
Now edit /etc/network/interfaces and create a new stanza like this one (remember to change IP addresses – in bold – according to your personal network configuration)
iface tun0 inet static
# from pre-up to true on the same line
pre-up ssh -i /root/.ssh/VPN -S /var/run/ssh-vpn-tunnel-control -M -f -w 0:0 1.2.3.4 true
pre-up sleep 5
address 10.1.0.2
pointopoint 10.1.0.1
netmask 255.255.255.0
up route add -net 192.168.10.0 netmask 255.255.255.0 gw 10.1.0.1 tun0
post-down ssh -i /root/.ssh/VPN -S /var/run/ssh-vpn-tunnel-control -O exit 1.2.3.4
Just a copuple of notes: address is your VPN local endpoint address (say, your workstation) while pointopoint is the remote VPNaddress (your server), which are the two tunnel’s endpoints.
Now let’s go to the server.
Edit /etc/ssh/sshd_server, add the line
PermitTunnel point-to-point
and restart your sshd instance.
Now edit (or create) /root/.ssh/authorized_keys (remember, we are on the server now, not your workstation) and add a line like
tunnel="0",command="/sbin/ifdown tun0; /sbin/ifup tun0" ssh-rsa HERE IT GOES YOUR VPNkey.pub FROM YOUR WORKSTATION
now edit /etc/network/interfaces and add this stanza:
iface tun0 inet static
address 10.1.0.1
netmask 255.255.255.0
pointopoint 10.1.0.2
post-up /sbin/sysctl -w net.ipv4.ip_forward=1
post-up /sbin/iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth1 -j MASQUERADE
post-down /sbin/iptables -t nat -D POSTROUTING -s 10.1.0.0/24 -o eth1 -j MASQUERADE
post-down /sbin/sysctl -w net.ipv4.ip_forward=0
the post-up and post-down commands enable the network sharing between the VPN server endpoint and the remote LAN (it’s called masquerading), so you can access the remote LAN from your workstation and not only the remote server. Obviously you need to instruct your workstation with a dedicated static route to reach the remote LAN network, and this is the route add -net in your workstation config.
Now, bring up the tunnel on the workstation with
# ifup tun0
and you should be able to reach a remote server on your remote LAN, with traffic secured by OpenSSH encryption.
In an older post I explained how to create a bond interface in Debian Etch… now, this doesn’t work anymore due to some changes in Lenny.
So, long story short, first of all, install ifenslave
# apt-get install ifenslave-2.6
edit /etc/network/interfaces and add the bond0 config:
auto bond0
iface bond0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.1
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1
now edit /etc/modprobe.d/arch/x86_64 (change the filename depending on your architecture) and add these lines
alias bond0 bonding
options bonding mode=1 miimon=100 downdelay=200 updelay=200
Brief explanation:
For a more complete description of all the possible parameters, refer to Linux Documentation/networking/bonding.txt
After this, you can restart networking or reboot if you are working remotely and it should work without a problem. It did for me :)
If you happen to own a SPARC64 box, you’ll probably already know that even if the kernel is 64bit the userland comes from the normal SPARC Debian port, so it’s 32bit. Mysql is no exception, with all the 32bit limitations – mainly the 4GB RAM per process limit.
This is really a PITA because if you have a SPARC64 box probably it has got plenty of RAM and you want to use it at its full potential, without having to messing around with Solaris (yeah, I don’t like it very much, I’m sorry).
This guide covers Mysql 5.1 installation in Debian Lenny, so we have to use SID repositories.
# echo "deb http://ftp.de.debian.org/debian/ sid main" >> /etc/apt/sources.list
# echo "deb-src http://ftp.de.debian.org/debian/ sid main" >> /etc/apt/sources.list
then let’s edit our apt preferences to avoid massive update on next dist-upgrade :)
# vim /etc/apt/preferences
Package: *
Pin: release a=stable
Pin-Priority: 900
Package: *
Pin: release a=sid
Pin-Priority: 100
and then update our repo list
# aptitude update
And here we go:
# apt-get build-dep mysql-server-5.1
# mkdir /tmp/mysql-build; cd /tmp/mysql-build
# apt-get source mysql-server-5.1
# vim mysql-dfsg-5.1*/debian/rules
here we touch a little the rules for compiling cause there are a couple of things that are not going to work by default.
The MAKE_J variable doesn’t work very well, so you can modify the grep to look for “CPU” instead of “processor” or you could hardcode it to the number of processor you have. This will make compilation a lot faster.
MAKE_J = -j$(shell if [ -f /proc/cpuinfo ] ; then grep -c CPU* /proc/cpuinfo ; else echo 1 ; fi)
then edit the CFLAGS variable because it’s used to compile some library that will ignore the environment variables we are going to set later in this howto.
CFLAGS=$${MYSQL_BUILD_CFLAGS:-"-O3 -DBIG_JOINS=1 -m64 -mcpu=niagara2 ${FORCE_FPIC_CFLAGS}"} \
it should be about line 73. Please note that -m64 will make it 64bit so it’s mandatory while the mcpu flag it’s to optimize the executable for your CPU. In my case it’s a niagara2 chip but you can use another CPU as well. Check the GCC documentation for more details
Save and quit and then we can start with the compilation process:
# export CFLAGS="-m64 -mcpu=niagara2 -O2 -g"
# export CXXFLAGS="-m64 -mcpu=niagara2 -O2 -g"
# export CPPFLAGS="-m64 -mcpu=niagara2 -O2 -g"
# export LDFLAGS="-m64 -mcpu=niagara2 -O2 -g"
# export DEB_BUILD_OPTIONS="nocheck"
# debuild -us -uc --preserve-env
that’s it. After some minutes (depending on your HW), you should have in /tmp/mysql-build all your new DEBs which you can install with dpkg -i. I advice to install the stock mysql-server-5.1 with aptitude before to get all dependencies installed, then you can use dpkg with your new DEBs.
Sometimes you may in need to use an external SMTP provider to send your emails, and usually ISPs give instruction on how to configure mail clients such as Outlook or Thunderbird. But what if you are already using an internal SMTP server such as Postfix?
These guidelines are for Debian (but may be helpful with other systems as well) and are related to Postfix. The SMTP provider in the example is AuthSMTP which is a well known provider for SMTP relaying.
Given you already have a working Postfix environment, first of all edit your main.cf and add these lines:
relayhost = [mail.authsmtp.com]
smtp_sasl_auth_enable=yes
smtp_sasl_password_maps=hash:/etc/postfix/sasl-passwords
smtp_sasl_mechanism_filter = digest-md5
smtp_sasl_security_options=
then, create with $EDITOR a file called /etc/postfix/sasl-passwords and fill it with something like this:
[mail.authsmtp.com] yourusername:yourpassword
then, compile the map file
# postmap hash:/etc/postfix/sasl-passwords
now we are almost done, just restart postfix and it should work.
Now, probably it won’t really work and you’ll start to see messages like these in your postfix log:
warning: SASL authentication failure: No worthy mechs found
SASL authentication failed; cannot authenticate to server mail.authsmtp.com
that’s because you are missing some SASL packages from Debian. Issue
# aptitude install libsasl2-modules
and it should install all the missing packages and make the thing work :)
Hello,
Maybe you are interested on installing untrusted packages on your Debian box, but by default you are prompted with this prompt:
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!
Untrusted packages could compromise your system’s security.
You should only proceed with the installation if you are certain that
this is what you want to do.
untrusted_package
Do you want to ignore this warning and proceed anyway?
To continue, enter “Yes”; to abort, enter “No”:
This is fine, since it warns you about it, but it breaks non-interactive scripts, because needs user confirmation.
What then? the solution is easy, you only need to tell to aptitude that you want to use those packages without user confirmation.
From aptitude manual:
Option: Aptitude::CmdLine::Ignore-Trust-Violations
Default: false
Description: In command-line mode, causes aptitude to ignore the installation of untrusted packages. This is a synonym for Apt::Get::AllowUnauthenticated.
Just go!
# aptitude -o Aptitude::Cmdline::ignore-trust-violations=true -y install your_untrusted_package
WARNING: untrusted versions of the following packages will be installed!
Untrusted packages could compromise your system’s security.
You should only proceed with the installation if you are certain that
this is what you want to do.
untrusted_package
*** WARNING *** Ignoring these trust violations because
aptitude::CmdLine::Ignore-Trust-Violations is ‘true’!
Writing extended state information… Done
It does not use an interactive prompt and of course your script will continue :)
See you!
After getting iSCSI working on Debian Etch the next thing to do is to set up multipath to get redundancy in case one path from the SCSI client to the SCSI target fails.
First, let’s digg a bit more in depth about what a path is, what can go wrong and what we can do to prevent it. Usually in a simple iSCSI environment there are two network interfaces dedicated to the remote storage, each one connected to a distinct ethernet switch and each switch connected to the a distinct ethernet interface in the host SAN. Then here you have two separated controller cards (let’s call them A and B) which connect to the same logical volume (a RAID array.. so here redundancy is already covered). I repeat, this is the simplest redundant scenario, in which you can have redundancy, a good fault-tolerance and can parallelize via round-robin the requests from the initiator to the host target.
Continue reading
I guess the fact I’m here writing again on this topic goes for that definitive I put in the title the first time :) So obviously it was not so definitive, and here we are again with a, I hope, better and improved version.
This time we are going to use th backports repository and the Etcn’n’half kernel, cause they provide a better and far more stable support for iSCSI under Debian (Etch).
So, first of all add the backports repository:
echo "deb http://www.backports.org/debian etch-backports main contrib non-free" >> /etc/apt/sources.list
and do some basic stuff:
# aptitude update
# aptitude install debian-backports-keyring
# aptitude update
Now, let’s install the newer 2.6.24 kernel from the Debian Etch’n’half project (note: it’s present in the officila Debian repository, it doesn’t come from the backports.org one)
# aptitude install linux-image-2.6-amd64-etchnhalf # remove amd64 if you're on x86_32
now here, if you are a Broadcom NeteXtreme 2 user (lsmod|grep bnx2), be careful and remember to install these NEW package before rebooting, or you will have an unpleasant surprise
# aptitude install firmware-bnx2
This is due to a change in newer Linux versions
Then reboot, cross your fingers and then install the newer open-iscsi package:
# aptitude install -t etch-backports open-iscsi
Everything should be ok and this time you should have all the config files in the right place, a proper script to mount/unmount iSCSI target devices at boot time and so on…
Anyway, I still prefer the old-school config file, so usually I replace the Debian stock one with something like this:
node.active_cnx = 1
#node.startup = manual
node.startup = automatic
#node.session.auth.username = dima
#node.session.auth.password = aloha
#node.session.timeo.replacement_timeout = 15
node.session.timeo.recovery_timeout = 15
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.MaxConnections = 0
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536
I have highlighted one line because that parameter is used to choose the timeout after which an iSCSI device is considered dead, and thus that path discarded (we’ll talk about paths later).
So, time to discover new devices now:
# /etc/init.d/open-iscsi restart
# iscsiadm -m discovery -t sendtargets -p $SAN_IP_ADDRESS
# /etc/init.d/open-iscsi restart
check out your dmesg output and look for new /dev/sdX devices.
Some partitioning and formatting later, you can edit your fstab with something like this
/dev/sdb1 /mnt/files ext3 defaults,auto,_netdev 0 0
and you should be done!
Ok, maybe this is a little bit arrogant title :) but since I’ve experienced more than a problem/issue when installing iSCSI initiator support in Debian 4.0 Etch, I think that this howto could help people setting up their first open-iscsi in Etch (in which open-iscsi is UTTERLY broken, let me say it loud).
First of all, install open-iscsi
aptitude install open-iscsi
and remove the broken init scripts (they are going to give you lots of headaches when rebooting, if you don’t do this.)
update-rc.d -f open-iscsi remove
Continue reading
DISCLAIMER: this is not an howto, it’s just a reminder for myself and a tip for someone who already knows LVS (Linux Virtual Server) basics.
So, if you need to use a Linux as a real server behind a LVS and you’re using kernel 2.6.x, you will know that if you try a
ifconfig lo:0 192.168.1.131 -arp netmask 255.255.255.255 up
then arping from an external host will be answered ANYWAY by your host, and this is a VERY BAD THING in an LVS environment (cause the client will contact directly only one real server and will not pass always through the virtual server). This could seem a bug cause we are using the -arp switch in ifconfig which should tell the kernel to ignore the ARP replies for this IP.
To solve this problem, you have to change these kernel settings with sysctl:
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
in sysctl.conf (you can use sysctl net.ipv4.conf.eth0.arp_ignore=1 for example if you want to give it a try before).
With these parameters set, if you try to arping the lo:0 IP address from an external host, it won’t answer, but nonetheless your real server will accept the packets sent by the director of the LVS system.
I’ve tried this in Debian.
The eternal fight between admins and computers 