Sie sind hier

Debian

Changing/Renewing GPG key procedure?

I know I'm a little late with this, but I want to renew GPG key and change it from DSA to RSA. The length of my ElGamal key is 1024, which is not that good for todays standard. When searching on Planet Debian, I found some few HowTos, especially that by Ana Guerrero.

Are there any other tips or caveats than those mentioned in her blog? Is an RSA key with a length of 4096 state of the art at the moment? Is it acceptable to send the new key sign (and maybe encrypted) to all those that already had signed my old key to get the new key signed?

Comments are welcome, dear Lazy Web!

Kategorie: 

Happy New Year - Frohes Neues Jahr 2011

Happy New Year to all my readers! Frohes Neues Jahr allen meinen Lesern!

WebDAV as webdrive on OSX

I'm using WebDAV on Lenny and on Squeeze now for some time for syncing my bookmarks and calendars which is working just fine. But now I want to extend my WebDAV in order to use it as an external storage. The only problem is: it doesn't workon OSX! D'oh!

Basically I followed several HowTos on the Net, so I ended with this configuration so far: 

     DavLockDB /path/to/DAVLockDB/DAVLockDB
     <Directory /path/to/webdav/>
        DAV On
        AuthType Digest
        AuthName "realm"
        AuthUserFile /path/tot/.htdigest
        Require valid-user
        Options +Indexes
        AllowOverride None
        Order allow,deny
        Allow from all
        <LimitExcept GET PUT POST OPTIONS DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
                RewriteEngine Off
        </LimitExcept>
     </Directory>

I can connect to and browse the WebDAV directory, but I can't upload new files - neither with Finder on OSX nor with cp on command line in OSX. When using Finder I get the following errors: 

For non-Germans: it says that the process couldn't be completed because the object is still in use.

Error -36 seems to be a generic I/O error in OSX and you can find many hits when you do a search in your favorite search engine. The Apache logs report lots of these lines: 

==> /var/log/apache2/domain-ssl-error.log <==
[Thu Dec 09 21:23:35 2010] [error] [client 2001:6f8:90e:900::2] client denied by server configuration: /var/www/net/domain/path/to/Files/._Cam-EG_20101113015900_MD 3.avi

==> /var/log/apache2/domain-ssl-access.log <==
[09/Dec/2010:21:23:35 +0100] rostock.ip6.windfluechter.net 2001:6f8:90e:900::2 - "GET /path/to/Files/._Cam-EG_20101113015900_MD%203.avi HTTP/1.1" 403 250 "-" "WebDAVFS/1.8.1 (01818000) Darwin/10.5.0 (i386)"

When copying some files with cp on OSXs command line I get these kind of errors: 

$ cp -r Desktop/AIDAluna_KameraArchiv_Geiranger /Volumes/ij/Files/
cp: /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/PRIVATE/AVCHD: Operation not permitted
cp: Desktop/AIDAluna_KameraArchiv_Geiranger/PRIVATE/AVCHD: unable to copy extended attributes to /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/PRIVATE/AVCHD: Operation not permitted
cp: /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/PRIVATE/AVCHD/.DS_Store: No such file or directory
cp: /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/PRIVATE/AVCHD/AVCHDTN: No such file or directory

Funny enough directories were created and some files were copying although OSX complains about "Operation not permitted": 

$ du -sch  /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/*
 10M    /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/DCIM
2,5K    /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/MISC
2,0K    /Volumes/ij/Files/AIDAluna_KameraArchiv_Geiranger/PRIVATE
 10M    total

Of course the directory on the webserver has sufficient permissions and copying files to it is working just fine with Windows as well as Debian Sid. But anyway, is there something I'm missing in WebDAV configuration or can I do something in OSX to make it work? Using a third party application on OSX is something I would like to avoid, but when nothing else will help, I'm open for suggestions.

Kategorie: 

Frozen Squeeze, broken packages and bug reports

Squeeze is frozen for some time now and will be released when it's ready, of course. Currently, I have at least two packages that have reported bugs, but it seems that they are making no progress. The first package is BackupPC.One of the bugs is #600654 and the other is #601843. Where as the first is just a cosmetic bug displaying filesystem usage of the backup volume, the other seems to have a functional impact: the backup pool doesn't get cleaned up properly each night.

Sadly the maintainer seems a little bit absent, so maybe someone else can do a NMU to get BackupPC into shape for release? Would be nice, though... ;-) 

The other package is spamassassin or more exactly libnetaddr-ip-perl and bug #601601. Whereas the BackupPC maintainer is rather quiet, there's lot of activity for the other bug but still I get these errors when running Spamassassin by cron: 

netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included
netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included

Although I'm confident that #601601 will be solved soon, I don't really know about the BackupPC bugs, except writing additional info mails to those bugs with "add me!" comment.

UPDATE 17.11.2010:
libnetaddr-ip-perl (#601601) seems to be fixed now.

Kategorie: 

Grub on RAID and Configuration

I've been running grub for quite a long time on my machine, but when I rebooted the other day, I noticed that there's currently a problem with the grub installation on my system: it doesn't boot anymore! ;)

My machine has 3 drives, with an LVM for the data on a RAID5. Then there is another RAID1 for /boot. This worked all the years quite reliable with grub. Now grub complains that it can't find the kernel anymore. The reason seems to be (from /boot/grub/grub.cfg):

echo    'Loading Linux 2.6.32-5-amd64 ...'
linux   /boot/vmlinuz-2.6.32-5-amd64 root=UUID=36213d56-67cf-428d-b801-4171fd9d6943 ro  vga=775
echo    'Loading initial ramdisk ...'
initrd  /boot/initrd.img-2.6.32-5-amd64

For some reason I don't know there's a /boot in front of /vmlinuz... which prevents loading the kernel. There's a "set root='(md0)'" line in the config as well, but I assume that this is correct, because /dev/md0 is my /boot on RAID0. The rootfs is on /dev/md2, another RAID0. So, I can't set root='md2' because there's no /boot/grub directory in the first place.

When I editing the linux and initrd lines in the boot prompt and remove the /boot, everything is fine and my system boots up just fine.

Was there an intended change in grub-pc package that causes this behaviour or is ist just a plain bug?

Kategorie: 

Upgrading to Squeeze - and suddenly CGI doesn't work anymore

Before I upgraded from Lenny to Squeeze, all my CGI scripts were working properly. The CGI scripts has been executed by Apache and resulted in rendered webpage. After the upgrade to Squeeze all those CGI scripts stopped been executed but instead started to get displayed as a plain text.

Common to all those CGI scripts is that they have .phtml as suffix, but the bang path/shebang consists of "#!/usr/bin/python". As an example you can have a look at Buildd.Net and its scripts like this one. The section in Apaches config looks like this: 

        <Directory /home/builddnet/unstable/WWW/cgi/>
                Options -Indexes +ExecCGI +FollowSymLinks
                AddHandler cgi-script .cgi .sh .pl .py .phtml
                Order allow,deny
                Allow from all
        </Directory>

So, I would expect that the CGI script handler will get executed when loading a *.phtml file and that the shebang would be honoured. Funny enough: when I rename that script to *.cgi it works.

I haven't figured out yet, what causes this beahviour or what have changed during the upgrade - and how to revert to the old behaviour. So, dear lazyweb, can you give me some hints and pointers?

 

Kategorie: 

Upgrading request-tracker 3.6 to 3.8 on Squeeze

Today I had some problems with request-tracker in version 3.6 on Squeeze, coming from Lenny: although I was able to write mails to the ticket system and was able to receive mails from it when creating new tickets, I was unable to send replies to tickets to the requestor. Instead of dealing around with 3.6 I tried to upgrade to rt 3.8. Basically the upgrade went fairly well, except for my PostgreSQL database. It depends on postgresql-client which is a virtual package for postgresql-client-8.4. As learned lately postgresql-8.4 is somewhat uninstallable on Squeeze at the moment.

So, I needed to make some sort of backport for rt3.8-db-postgresql_3.8.8-3_all.deb, which was quite easy. Instead of

Depends: ${misc:Depends}, libdbd-pg-perl (>= 1.41),
 postgresql-client (>= 7.4)
Suggests: postgresql | postgresql (>= 7.4)

I changed the lines to this: 

Depends: ${misc:Depends}, libdbd-pg-perl (>= 1.41),
 postgresql-client-8.3 (>= 7.4)
Suggests: postgresql-8.3 | postgresql (>= 7.4)

Now I was able to install request-tracker3.8 successfully, upgrade the database and enjoy the new shiny version of rt. I'm unsure whether I needed to edit/save the Respond scrips as well to make the mail sending again or not. But that shouldn't be big show blocker either.

Anyway, I think I'll write a bug report for rt 3.8 tomorrow... It's always fun to find yet another bug when a new release is upcoming... :-)

UPDATE:
Bug report filed as #596926

Kategorie: 

Upgrading PostgreSQL 8.3 to 8.4 on Squeeze

Currently upgrading Debian Lenny to Squeeze is not that easy, because PostgreSQL 8.3 from Lenny is getting to be removed while PostgreSQL 8.4 won't be installed because of some dependency issues: 

# apt-get install postgresql-8.4 postgresql-8.4-postgis postgresql-contrib-8.4
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  postgresql-8.4: Depends: libgssapi-krb5-2 (>= 1.8+dfsg) but it is not going to be installed
                  Depends: libkrb5-3 (>= 1.6.dfsg.2) but it is not going to be installed
                  Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
                  Depends: postgresql-client-8.4 but it is not going to be installed
  postgresql-contrib-8.4: Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
E: Broken packages

Well, yes, I know Squeeze is still Testing and such, but as libkrb5-3 and libgssapi-krb5-2 are required but seem to be unavailable, I wonder when this issue will get solved? There seems no bug report for postgresql-8.4, libkrb5-3 or libgssapi-krb5-2. Is that for a reason? Or is the reason for uninstallable postgresql-8.4 something else?

UPDATE:

# apt-cache policy postgresql-8.4
postgresql-8.4:
  Installed: (none)
  Candidate: 8.4.4-2
  Version table:
     8.4.4-2 0
        500 http://ftp.de.debian.org squeeze/main Packages

# apt-cache policy libkrb5-3
libkrb5-3:
  Installed: 1.8.3+dfsg~beta1-1
  Candidate: 1.8.3+dfsg~beta1-1
  Version table:
 *** 1.8.3+dfsg~beta1-1 0
        500 http://ftp.de.debian.org/debian/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status
 

UPDATE 2:
This issue seems to be caused by #596678. Thanks Rhonda & Martin!

Kategorie: 

Solved: Problems with IPv6 and Bridging/Xen

Since I ordered a new dedicated rootserver, I had problems with my IPv6 setup. Thanks to Niggurath@#debian.de/ircnet and his tips, I finally found the reason for all the mess when I migrated from my old rootserver with Lenny to the new one running Squeeze.

The problem was that in /etc/sysctl.conf there was the following setting on the old server: 

net.ipv6.conf.all.forwarding=1

Due to a issue in Lenny, this setting had basically no effect on the old server. Sysctl.conf was called before the IPv6 interface went up, so this setting failed or never got active. Meanwhile in Squeeze IPv6 seems to be enabled at an earlier point in the boot process and the forwarding setting will succeed. This in return resulted in my not working IPv6 setup.

When I disable the line in sysctl.conf everything works just fine: the domU honors the Router Advertisments of radvd again and everything is fine again. Sometimes the solution is so simple, you can't find it yourself. :-) 

 

Kategorie: 

Problems with IPv6 and Bridging/Xen

I've been using IPv6 on my rootserver for some time now. Last week I migrated to a new rootserver and copied my domU/VM instances over to the new hardware. Everything is working fine so far - except IPv6. The network setup is the same as on the old server: the external interface is eth0. The domU/VMs are hooked up to a bridge, called xenbr0. There's another bridge for internal communication: xenbr1.

The dom0/Xen host itself seems reachable via IPv6. The /48 subnet is provided by Sixxs and is using a static 6-to-4 tunnel. But the VMs are not reliable reachable, although it is setup in the same way as it was on the old server and where it was working like a charme.

The configs of the hosts are these: 

Xen dom0
config old server new server
System Debian Etch
2.6.18-6-xen-amd64
linux-image-2.6.18-6-xen-amd64
linux-modules-2.6.18-6-xen-amd64
xen-hypervisor-3.0.3-1-amd64
xen-ioemu-3.0.3-1
xen-linux-system-2.6.18-6-xen-amd64
xen-tools
xen-utils-3.0.3-1
xen-utils-common

Debian Squeeze
2.6.32-5-xen-amd64
libxenstore3.0
linux-image-2.6.32-5-xen-amd64
xen-hypervisor-4.0-amd64
xen-linux-system-2.6.32-5-xen-amd64
xen-tools
xen-utils-4.0
xen-utils-common
xenstore-utils
xenwatch

/etc/sysctl.conf net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.default.proxy_arp=1
net.ipv4.ip_forward=1
net.ipv4.ip_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
/etc/xen/xend-config.sxp (network-script network-route)
(vif-script     vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vif-script vif-bridge)
(network-script network-route)
(dom0-min-mem 196)
(enable-dom0-ballooning yes)
(total_available_memory 0)
(dom0-cpus 2)
(vncpasswd '')
/etc/network/interfaces

# device: eth0
auto eth0
iface eth0 inet static
  address 85.10.209.30
  broadcast 85.10.209.31
  netmask 255.255.255.224
  up route add -net 85.10.209.0 netmask 255.255.255.224 gw 85.10.209.1 eth0 || true
  up ip route add 85.10.209.0/28 via 85.10.209.1 src 85.10.209.30 || true
  up route add default gw 85.10.209.1 || true

auto xenbr0
iface xenbr0 inet static
        address 85.10.209.30
        netmask 255.255.255.224
        pre-up brctl addbr xenbr0
        up route add -net 78.47.85.144/29 dev xenbr0  || true
        up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe55:197c dev xenbr0 ||true
        up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fe2f:481d dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe60:68be dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 || true

auto xenbr1
iface xenbr1 inet static
        address 192.168.x.254
        netmask 255.255.255.0
        pre-up brctl addbr xenbr1
        # some internal IPv4 routing


auto sixxs
iface sixxs inet6 v4tunnel
        address 2001:6f8:900:c6e::2
        netmask 64
        endpoint 212.224.0.188
        local 85.10.209.30
        ttl 64
        up ip link set mtu 1280 dev sixxs || true
        up ip route add default via 2001:6f8:900:c6e::1 dev sixxs || true
        up ip -6 route flush dev eth0 || true
        up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 || true
        down ip -6 route flush dev sixxs || true

 # device: eth0
auto  eth0
iface eth0 inet static
  address   178.63.83.84
  broadcast 178.63.83.127
  netmask   255.255.255.192
  gateway   178.63.83.65
  # default route to access subnet
  up route add -net 178.63.83.64 netmask 255.255.255.192 gw 178.63.83.65 eth0

auto xenbr0
iface xenbr0 inet static
        address 178.63.83.84
        netmask 255.255.255.192
        pre-up brctl addbr xenbr0
        up route add -host 178.63.83.104 dev xenbr0  || true
        up route add -host 178.63.83.105 dev xenbr0  || true
        up route add -host 178.63.83.106 dev xenbr0  || true
        up ip route add 178.63.123.128/26 dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe89:6c31 dev xenbr0 ||true
        up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fedc:af5f dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe08:8f40 dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 || true


auto xenbr1
iface xenbr1 inet static
        address 192.168.x.254
        netmask 255.255.255.0
        pre-up brctl addbr xenbr1
        # some internal IPv4 routing

     
auto sixxs
iface sixxs inet6 v4tunnel
        address 2001:6f8:900:c6e::2
        netmask 64
        endpoint 212.224.0.188
        local 178.63.83.84
        ttl 64
        up ip link set mtu 1280 dev sixxs || true
        up ip route add default via 2001:6f8:900:c6e::1 dev sixxs || true
        up ip -6 route flush dev eth0 || true
        up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 || true
        down ip -6 route flush dev sixxs || true

The config of one of the Xen domUs is this: 

sample domU config
config old server new server
system Debian Lenny
2.6.18-6-xen-amd64
Debian Lenny
2.6.32-5-xen-amd64
/etc/sysctl.conf net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.default.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.default.proxy_arp=1
kernel.shmmax=268435456
net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.default.proxy_arp=1
kernel.shmmax=268435456
/etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
        address 78.47.85.145
        netmask 255.255.255.248
        up ip route add 85.10.209.0/27 dev eth0
        up route add default gw 85.10.209.30 dev eth0
        up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 || true
        up ip -6 route add default via 2001:6f8:90e:1::1 || true       
        up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE || true

iface eth0 inet6 static
        address 2001:6f8:90e:145::1
        netmask 64
        gateway 2001:6f8:90e:1::1

auto eth1
iface eth1 inet static
        address 192.168.x.1
        netmask 255.255.255.0

# The primary network interface
auto eth0
iface eth0 inet static
        address 178.63.83.104
        gateway 178.63.83.84
        netmask 255.255.255.192
        broadcast 178.63.83.127
        up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 || true
        up ip -6 route add default via 2001:6f8:90e:1::1 src 2001:6f8:90e:1:216:3eff:fe89:6c31 || true
        up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE || true

iface eth0 inet6 static
        address 2001:6f8:90e:145::1
        netmask 64
        gateway 2001:6f8:90e:1::1

auto eth1
iface eth1 inet static
        address 192.168.x.1
        netmask 255.255.255.0

The dom0 seems to be reachable via IPv6 just perfectly fine. When trying to reach the domU I see packets going through the xenbr0 bridge and reaching the domU eth0 interface. The ICMP6 echo request packets (proto 58) are unanswered there, no echo replies. Strange enough it seems to work from time to time, but mostly not. I've also tried to set a generic default route like ip -6 route add default dev eth0, but still no improvement.

Did I miss something when migrating to the new server? Is there any mistake in the configs? Any suggestions are appreciated! :-)

UPDATE:
This is a tcpdump from the domU, doing a ping from dom0: 

07:35:29.308261 IP6 fe80::e46d:25ff:fe1f:317b > ip6-allnodes: ICMP6, router advertisement, length 56
07:35:29.329411 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 45, length 64
07:35:30.329439 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 46, length 64
07:35:30.451991 IP6 2001:418:4001:3::c657:b0c5 > vserv.windfluechter.net: ICMP6, echo request, seq 52836, length 64
07:35:30.481124 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:31.329906 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 47, length 64
07:35:31.481645 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:32.329284 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 48, length 64
07:35:32.481114 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:33.329951 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 49, length 64
07:35:34.329705 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 50, length 64

UPDATE #2:
The issue is finally solved. The solution can be found here.

Kategorie: 

Seiten

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer