BigSmoke

Smokes your problems, coughs fresh air.

Page 36 of 52

UTP wiring

I’m always confused about which wiring scheme to use for UTP cables. After doing some research, it seems T568B is what you need. Wikipedia says that is doesn’t really matter, but crosstalk can be a problem for T568A in some esoteric situations:

Note that the only difference between T568A and T568B is that pairs 2 and 3 (orange and green) are swapped. Both configurations wire the pins “straight through”, i.e., pins 1 through 8 on one end are connected to pins 1 through 8 on the other end. Also, the same sets of pins are paired in both configurations: pins 1 and 2 form a pair, as do 3 and 6, 4 and 5, and 7 and 8. However the different pairs in an Ethernet cable are identical,[dubious – discuss] so one can use cables wired according to either configuration in the same installation without significant problem; problems involving crosstalk can occur (which is normally minimized by correctly twisting a pair together), but are usually insignificant in all but the most stringent specifications such as Category 6 cable. The primary thing one has to be careful of is not to accidentally wire the ends of the same cable according to different configurations (except if one intends to create an Ethernet crossover cable).

Making Coyote Linux work with KPN ADSL

The Dutch ISP KPN gives you a modem+router to access the internet. The router they give you is a custom version of an Alcatel Speedtouch (model varies) and is extremely limited. I don’t use any VOIP services, so I replaced that router with a Speedtouch 546 (which supports DHCP spoofing) so that I can use my own Coyote Linux based router.

Once the DHCP spoofing was configured everything basically worked, except for the fact that KPN’s default gateway is outside of the current subnet. It is said that only Windows knows how to deal with this. To work around this, you need to add two routes: one to tell on which ethernet port the IP address of the gateway can be found and one to set it up as default gateway.

To do that in Coyote Linux, make this script and name it /etc/rc.d/rc.add-kpn-routes:

# KPN has a router that is outside the subnet, therefore these routes need to be added manually. Only windows can handle it normally.
 
log_file="/var/log/add-kpn-routes"
 "==========" >> $log_file
 "Called with param: $1" >> $log_file
 "Current route:" >> $log_file
route -n >> $log_file
 "" >> $log_file
 `cat /etc/dhcpc/eth1.info`
 "route add $dhcp_router dev eth1" >> $log_file
route add $dhcp_router dev eth1
 "route add default gw $dhcp_router eth1" >> $log_file
route add default gw $dhcp_router eth1
 "==========" >> $log_file

Then in /etc/rc.d/rc.line_up add:

# Add KPN routes
[ -x /etc/rc.d/rc.add-kpn-routes ] && . /etc/rc.d/rc.add-kpn-routes $1

When Coyote has started, it can take a while for the script to run, but it works eventually.

Don’t forget to add a newline at the end of the last line. The default editor Coyote uses doesn’t do that by default and I can somewhat remember that bad things happen when that newline misses.

Creating a DRBD device

This post is no longer up-to-date. See this one.

When you’re clustering machines, a distributed remote block device (DRBD) comes in handy. It’s basically RAID1 over a network. I used Ubuntu Server 9.10 to create a test drbd setup.

First install drbd:

aptitude -P install drbd8-utils

Then put this config, with modifcations, on both nodes:

global {
  usage-count no;
}
common {
  protocol C;
 
  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh wiebe@halfgaar.net";
  }
 
  syncer {
    # The default is supposed to be maximum speed, but it was dead slow without this directive
    rate 500k;
    csums-alg md5;
  }
 
  disk {
    on-io-error detach;
  }
 
  net {
    data-integrity-alg md5;
  }
}
resource r0 {
  meta-disk internal;
  disk      /dev/sda2;
  device    /dev/drbd1;
 
  on storage00 {
    address   192.168.1.50:7789;
  }
  on storage01 {
    address   192.168.1.51:7789;
  }
}

Then on both nodes:

  • drbdadm create-md r0
  • drbdadm up r0

Then on the primary node, execute this to start the sync:

drbdadm -- --overwrite-data-of-peer primary r0

Data from the current node will now be used as base.

You can also make a drbd device with data on one of the underlying devices, but I didn’t try that, so go to the drbd website for docs on that.

Disabling Zimbra’s spam learning

Zimbra learns ham and spam by sending it to certain mailboxes. For our setup, this doesn’t work (easily), because our server is configured to always send mail to another SMTP server and not do any local delivery. I did that, because our zimbra server is not actually on the domain it thinks.

To disable the learning accounts, I did this:

zmprov mcf zimbraSpamIsSpamAccount ''
zmprov mcf zimbraSpamIsNotSpamAccount ''
zmcontrol stop
zmcontrol start

I didn’t delete the accounts, so I can enable it later.

To enable it, I guess I have to configure these two accounts on our hosting provider’s servers, fetch and deliver them to Zimbra and it works. I’ll do that some time…

Quickly removing and adding bootscripts in Debian

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.

My time compared to UTC

I always forget what my timedifference is with UTC, so here it is:

  • In winter I’m UTC+1
  • In summer I’m UTC+2

So, when it’s 10:00 here, I have to set a system clock to 9:00 in the winter and 8:00 in the summer.

Using Fetchmail to deliver to another SMTP host and user

If you want to fetch mail from several accounts and relay them to another SMTP host and user, you can use fetchmail. Define a .fetchmailrc like this:

defaults proto POP3 no keep fetchall smtphost smtp.example.net ssl
set no bouncemail
set no spambounce
set logfile /home/mailchecker/.fetchmail.log
 
poll mail.initfour.nl user "test" pass "test" smtpname user@domain.org
# more accounts to poll... 

Preventing NameVirtualHost *:80 has no VirtualHosts

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.

« Older posts Newer posts »

© 2024 BigSmoke

Theme by Anders NorenUp ↑