chr.istoph, der Blog

Beim booten eines Servers standen die Logical Volume nicht zur Verfügung. Beim Aufrufen von lvs kam folgende fehlermeldung die einen hinwies auf die volle Platte gab.
# lvs
No volume groups found
/etc/lvm/cache/.cache.tmp: write error failed: Auf dem Gerät ist kein Speicherplatz mehr verfügbar


# ls /etc/lvm/cache/.
./ ../ .cache .cache.tmp


Nach dem aufräumen des Root-Filesystems muss man erst das pv nach vgs durchsuchen.
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg1" using metadata type lvm2


# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv1 vg1 -wi--- 100,00g


Anschließend musste man das vg aber noch starten.
# vgchange -a y vg1
7 logical volume(s) in volume group "vg1" now active


Heute war ich auf einem System bei dem sich die Updates bei SSH aufgegangen haben.

Preparing to replace openssh-client 1:5.5p1-6+squeeze4 (using .../openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb) ...
Unpacking replacement openssh-client ...
dpkg: error processing /var/cache/apt/archives/openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb (--unpack):

configured to not write apport reports
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Da ein einfaches ls keine besonderen auffällikkeiten ergaben, musste es mit den erweiterten ext Dateisystemberechtigungen zusammen hängen. Das überprüfen ging dann folgendermaßen:
lsattr /usr/bin/ssh
-u--ia------------- /usr/bin/ssh


Die liste der einzelnen Berechtigungen findet man hier: chattr.
Für meine Fall müssen die folgenden Attribute entzogen werden:
chattr -i /usr/bin/ssh
chattr -a /usr/bin/ssh


lsattr /usr/bin/ssh
-u----------------- /usr/bin/ssh


Nach einer Neuinstallation mittels: apt-get install -f lies sich ssh ordentlich Installieren.

Quelle: howtoforge.com

Heute habe ich fehler auf einem Kunden System gehabt, das das Debian Paket man-db nicht richtig installiert werden konnte.
# apt-get install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/DbDriver/File.pm line 44, chunk 3.
Use of uninitialized value in -e at /usr/share/perl5/Debconf/DbDriver/File.pm line 46, chunk 3.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debconf/DbDriver/File.pm line 47, chunk 3.
Use of uninitialized value $directory in -d at /usr/share/perl5/Debconf/DbDriver/File.pm line 48, chunk 3.
Use of uninitialized value $directory in concatenation (.) or string at /usr/share/perl5/Debconf/DbDriver/File.pm line 49, chunk 3.
debconf: DbDriver "config": mkdir :No such file or directory
Setting up man-db (2.6.2-1) ...
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/DbDriver/File.pm line 44, chunk 3.
Use of uninitialized value in -e at /usr/share/perl5/Debconf/DbDriver/File.pm line 46, chunk 3.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debconf/DbDriver/File.pm line 47, chunk 3.
Use of uninitialized value $directory in -d at /usr/share/perl5/Debconf/DbDriver/File.pm line 48, chunk 3.
Use of uninitialized value $directory in concatenation (.) or string at /usr/share/perl5/Debconf/DbDriver/File.pm line 49, chunk 3.
debconf: DbDriver "config": mkdir :No such file or directory
dpkg: error processing man-db (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
man-db
E: Sub-process /usr/bin/dpkg returned an error code (1)

Schnell war gefunden das der debconf Ortner fehlte:
mkdir /var/cache/debconf
apt-get install -f

Manchmal kommt es vor das meine einen Server die IP ändert, das System neu aufsetzt bzw. den SSH key erneuert. Wenn unter dem Namen oder der IP bereits ein andere Rechner in der known_hosts eingetragen war, warnt SSH standardmäßig davor vor dem Login um auf MITM attacken abzuwehren.

ssh 192.168.0.22
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for blog.chr.istoph.de has changed,
and the key for the corresponding IP address 192.168.0.22
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:111
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
1e:14:52:64:3a:55:a2:02:00:00:00:22:00:84:d4:25.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:94
RSA host key for blog.chr.istoph.de has changed and you have requested strict checking.
Host key verification failed.

Blöd ist das natürlich wenn man nur eine Rescue CD eingelegt hat und den Rechner warten will. Dabei hilft es die SSH known_hosts Datei nach /dev/null zu Mappen um
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no 192.168.0.22

Wenn im einem localen netz die Server immer wieder neue DHCP Adressen bekommen, kann es hilfreich sein die internen Adressen ganz von der prüfung durch die known_hosts Datei auszuschließen. Dafür fügt man in der ~/.ssh/config Datei folgende Zeilen exemplarisch an:
Host 192.168.0.* 192.168.122.*
User root
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

Da ich gerade mal wieder eine Viertelstunde damit vertan habe, diesen Befehl zu finden, dokumentiere ich ihn hier.

Ich suchte den Befehl, mit dem ich sehen kann, aus welcher Paktequelle ein Programm kommt. Dies bauchte ich um heraus zu finden ob das Paket ggf. aus einer PPA kommt.

apt-cache policy qemu
qemu:
  Installiert: (keine)
  Kandidat: 0.12.3+noroms-0ubuntu9.16
  Versions-Tabelle:
     0.12.3+noroms-0ubuntu9.16 0
        500 http://mirror.bauhuette.fh-aachen.de/ubuntu/ lucid-updates/universe Packages
     0.12.3+noroms-0ubuntu9.15 0
        500 http://mirror.bauhuette.fh-aachen.de/ubuntu/ lucid-security/universe Packages
     0.12.3+noroms-0ubuntu9 0
        500 http://mirror.bauhuette.fh-aachen.de/ubuntu/ lucid/universe Packages