ubuntu

Ubuntu Xenial preseed: „The installer has detected that the following disks have mounted partitions“

Leave a Comment

Ich bastel auf Arbeit gerade neue Installstick’s für unsere Software, da ja Xenial vor der Tür steht. Mit Hilfe einer Preseed Konfiguration kann ich schon vorher festlegen was während der Installation wie konfiguiert werden soll, ohne händisch alles auszuwählen. Heute lief ich bei der Partitionierung permanent in einen Fehler. Jedes mal beim booten des Sticks mountete er /dev/sda1 nach /media und meldete dann beim partitionieren:

The installer has detected that the following disks have mounted partitions

Ok, gemountete Partition. Sag ich ihm halt mit folgendem in der preseed.cfg, dass alle aktiven Parititonen vorher ausgehängt werden sollen:

d-i partman/unmount_active boolean true

Das brachte allerdings nichts, da die Option scheinbar einfach ignoriert wird. Nach kurzem suchen, fand ich dann auch direkt den passenden Bugreport. Das Problem existiert bereits seit 14.04 und scheint ein Problem von debian-installer-utils und/oder partman-base zu sein. Es scheinen meines erachtens beide Recht zu haben, denn zum einen scheint ja der debian-installer, ohne (für mich) ersichtlichen Grund, Partitionen nach /media zu mounten und zum anderen scheint die umount_active question auf false gesetzt, wodurch partman das dann auch nicht abfängt.

Für mich brachte dann, wie auch im Bugreport erwähnt, folgende Zeile in der preseed.cfg den Erfolg:

d-i preseed/early_command string umount /media

LXC Ubuntu Template failed unter Debian

Leave a Comment

Als ich heute unter Debian Ubuntu in einen LXC Container installieren wollte, schlug dies fehl mit folgender Meldung:

I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
I: Retrieving Release 
E: Failed getting release file https://mirrors.kernel.org/debian/dists/precise/Release

Dazu gibt es auch schon ein entsprechendes Ticket auf Github. Die Lösung ist ganz einfach das Paket ubuntu-archive-keyring zu installieren. Cooler wäre natürlich wenn man entweder direkt darauf hingewiesen wird, oder es in die Abhängigkeiten von LXC aufgenommen wird.

Default Kompressionsalgorithmus von debuild ändern

Leave a Comment

Auf Arbeit laufen große Teile der Clients noch auf Ubuntu 12.04 Precise, weshalb ich dafür natürlich auch meist Pakete dafür baute. Gestern habe ich ein paar Pakete für 14.04 Trusty bauen müssen und hab dabei fast die Kriese bekommen. Das bauen an sich machte keine Probleme, allerdings unser Repository, welches schon etwas in die Jahre gekommen ist. Ich bekam nun bei erstellen des Repository’s jedes mal 

E: This is not a valid DEB archive, it has no 'data.tar.gz', 'data.tar.bz2' or 'data.tar.lzma' member
E: Errors apply to file '/var/www/linux/dists/gpl-trusty/main/binary-i386/libmd5-perl_2.03-1_all.deb'

Wenn ich mir das nun auf unserem Repository das Paket anschaute meldete der auch das damit etwas nicht stimmt. Gut hier ist es wieder meine eigene Schuld, denn ich las die Fehlermeldung nicht richtig, welche wie folgt lautete:

dpkg-deb: file `/root/gpl-trusty/main/libmd5-perl_2.03-1_all.deb' contains ununderstood data member data.tar.xz, giving up

Hätte ich mir diese und die vorhergehende Meldung mal direkt genauer angeschaut, hätte ich auch gesehen das er einfach mit dem Kompressionsalgorithmus XZ nicht klar kommt. Also Fazit, unter Trusty wurde der Default Kompressionsalgorithmus auf XZ gestellt, womit alte Systeme ein Problem haben. Nun muss ich also debuild beibringen das er wieder gzip als Default zu benutzen hat, was ich wie folgt getan habe:

  • Die Datei /usr/local/bin/dpkg-deb, mit folgendem Inhalt, erstellen
    • #!/bin/bash
/usr/bin/dpkg-deb -Zgzip $@
  • Folgendes noch in der .bashrc hinzufügen, da es in meinem Fall dauerhaft sein soll
    • alias debuild="debuild --preserve-envvar PATH"

    Anschließend nutzt dann debuild auch gzip und alles funktioniert. Es gibt auch noch andere Varianten debuild dazu zu bewegen gzip zu nutzen, wie beispielsweise die Datei debian/source/options mit folgendem Inhalt anzulegen:

    compression = "gzip"

    Dies ignorierte aber debuild bei mir komplett.

    Quelle: http://comments.gmane.org/gmane.linux.debian.devel.devscripts/9977

    PS: Dank geht auch wieder an meinen Kollegen, der mir bei der Aufklärung behilflich war.

    Diskfilter writes are not supported

    2 Comments

    Auf Servern mit Ubuntu 14.04 bekomme ich beim booten schon immer folgenden Fehler angezeigt:

    error:  Diskfilter writes are not supported

    Dies ist ein Bug, der Auftritt wenn man die Root, oder wenn einzeln die Boot Partition, in einem RAID oder LVM anlegt. Ein sehr gute ausführliche Beschreibung, warum der Bug auftritt gibt es in diesem Forumbeitrag: Beitrag bei askbuntu.com Da dieser alles ziemlich gut erklärt, werde ich das jetzt nicht nochmal niederschreiben, sondern nur die Lösung:

  • Download der gepatchten GRUB Header Datei
    • wget https://gist.githubusercontent.com/rarylson/da6b77ad6edde25529b2/raw/99f266a10e663e1829efc25eca6eddb9412c6fdc/00_header_patched
  • Sichern der Originaldatei und verschieben der neuen
    • mv /etc/grub.d/00_header /etc/grub.d/00_header.orig
mv 00_header_patched /etc/grub.d/00_header
  • Altes Script deaktivieren und neues aktivieren
    • chmod -x /etc/grub.d/00_header.orig
chmod +x /etc/grub.d/00_header
  • GRUB updaten
    • update-grub

    Wie man in dem Beitrag auch lesen kann ist das ab 15.04 gefixt. Warum sie den Patch nicht in 14.04 einfließen lassen, versteh ich nicht.

    apt-get force IPv4

    3 Comments

    Ich hatte letzte Woche auf Arbeit das Problem, das scheinbar das IPv6 bei einem Kunden kaputt war, weshalb ich kein apt-get update durchführen konnte, da er die IP nicht erreichen konnte. Also musste ich apt-get dazu bewegen doch bitte IPv4 zu nutzen. Ab Version 0.9.7.9~exp1 geht das wie folgt:

    apt-get -o Acquire::ForceIPv4=true update

    Da es sich in diesen Fall aber um ein Precise handelte mit einer älteren apt-get Version muss hier anders vorgegangen werden. Und zwar muss in /etc/gai.conf folgende Zeile einkommentiert werden:

    precedence ::ffff:0:0/96  100

    pgAdmin III: Passwort expired nach Bearbeiten von Login Rollen

    Leave a Comment

    Mein Kollege und ich waren heute extrem verwirrt. Er wollte mir einen Benutzer in postgres Datenbank anlegen und tat dies auch. Gleichzeitig änderte er bei sich noch eine der Privilegien, danach stürzte bei ihm pgAdmin ab. Keine Seltenheit, nun kam aber der kuriose, er konnte sich nicht mehr einloggen, Grund: keiner. Dann loggte er sich mit meinem User ein, änderte auch hier ein Privileg und schon konnte ich mir auch nicht mehr einloggen. Beim connecten mal auf SSL require gestellt und nun bekamen wir die Meldung das das Passwort falsch ist. Also Passwort in der Datenbank auf der Console geändert, kein Login möglich. Auf der Console fiel uns dann irgendwann mal auf, das unsere Accounts plötzlich auf „Expired“ gestellt sind. Also das wieder Rückgängig gemacht, und schon ging es wieder.
    Dann änderten wir in pgAdmin nochmal die Privilegien, und siehe da, er stellt sofort beim speichern das Expiry Date auf den heutigen Tag. Grund dafür ist, das sobald die Properties eines Logins geöffnet werden, pgAdmin in dem Reiter Definition das Expiry Date auf den aktuellen Tag setzt, ohne darüber einen Hinweis einzublenden.

    Heißt, wenn ihr mit pgAdmin eine Benutzer bearbeitet, denkt daran das Expiry Date im Reiter Definition zu checken und gegebenfalls zu löschen.

    pgAdmin II Version: 1.18.1
    Ubuntu Version: 14.04

    Laut Changelog auf der pgAdmin Seite wurde das in Version 1.18.2 gefixt, scheinbar aber nur für Mac:
    2013-10-22 DP 1.18.2 Fix the handling of the „Valid Until“ date/time on the
    role dialogue on Mac [Dinesh Kumar].

    Redmine: ActionController::RoutingError

    Leave a Comment

    Gestern habe ich zum testen ein Plugin installiert, welches bei mir allerdings nur zu Error Meldungen über Error Meldungen in Error Meldungen führte. Ja ich weiß, redmine hat auch nenn Dev Environment, ich habe auch daraus gelernt…
    Jedenfalls nachdem ich alles zurück gerollt hab, stellte ich zu meinem erstaunen fest das im Redmine spezielle Funktionen nicht mehr funktionieren. Hier mal paar Beispiele:

    • Checklisten Plugin: Anlegen von Punkten nicht mehr durch Enter möglich, stattdessen tauchen nun Speichern und Abrechen Buttons auf die aber nicht funktionieren
    • Agile Plugin: Zeigt nur noch kaputte Task Charts an
    • Plugins wie das Redmine CRM People und Contacts Plugin können die Default Avatare nicht mehr finden

    Im production.log von Redmine zeigte sich dann bei jedem Aufruf, von nahezu jedem Plugin folgender Fehler. Ist hier ein Bsp. von Contacts

    ActionController::RoutingError (No route matches [GET] "/plugin_assets/redmine_contacts/stylesheets/contacts.css"):
  actionpack (3.2.21) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
  actionpack (3.2.21) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.21) lib/rails/rack/logger.rb:32:in `call_app'
  railties (3.2.21) lib/rails/rack/logger.rb:16:in `block in call'
  activesupport (3.2.21) lib/active_support/tagged_logging.rb:22:in `tagged'
  railties (3.2.21) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.21) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  /usr/lib/ruby/vendor_ruby/rack/methodoverride.rb:21:in `call'
  /usr/lib/ruby/vendor_ruby/rack/runtime.rb:17:in `call'
  activesupport (3.2.21) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  /usr/lib/ruby/vendor_ruby/rack/lock.rb:15:in `call'
  actionpack (3.2.21) lib/action_dispatch/middleware/static.rb:83:in `call'
  /usr/lib/ruby/vendor_ruby/rack/cache/context.rb:136:in `forward'
  /usr/lib/ruby/vendor_ruby/rack/cache/context.rb:245:in `fetch'
  /usr/lib/ruby/vendor_ruby/rack/cache/context.rb:185:in `lookup'
  /usr/lib/ruby/vendor_ruby/rack/cache/context.rb:66:in `call!'
  /usr/lib/ruby/vendor_ruby/rack/cache/context.rb:51:in `call'
  railties (3.2.21) lib/rails/engine.rb:484:in `call'
  railties (3.2.21) lib/rails/application.rb:231:in `call'
  railties (3.2.21) lib/rails/railtie/configurable.rb:30:in `method_missing'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:77:in `process_request'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:142:in `accept_and_process_next_request'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:110:in `main_loop'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler.rb:448:in `block (3 levels) in start_threads'

    Die Fehlermeldung ist dabei für jedes Plugin identisch, nur der Pfad variiert halt. Also erstmal auf dem System rummgeschaut was das Problem sein könnte – Pfade, Rechte etc. gecheckt, alles beim alten. Plugins deinstalliert und neu installiert, genau der selbe Fehler. Lösung fand ich dann schließlich hier. Man muss Apache also mitteilen wo plugin_assets zu finden ist, also muss folgendes in der entsprechenden Apache Conf für die Seite ergänzt werden:

    Alias "/plugin_assets/" /var/cache/redmine/default/plugin_assets/
        
                Allow from all
                Options -MultiViews
                Require all granted

    Was ich allerdings nicht verstehe ist, wieso dieses Problem vorher nicht auftauchtey, sondern erst nach einem fehlerhaften Plugin. Wenn da jemand vielleicht was genaueres weiß wäre ich hoch erfreut wenn dieser es mir verrät. :)

    Update zum Artikel Redmine aus dem PPA unter Ubuntu 14.04 installieren

    Leave a Comment

    Ich habe gestern festgestellt das es bei Ubuntu 14.04.2 während der Installation von redmine-mysql zu einem Fehler kommt, weil während der Installation der activerecord-mysql-adapter noch nicht installiert ist. Die Meldung sieht dann so aus:

    rake aborted!
Please install the mysql adapter: `gem install activerecord-mysql-adapter` (cannot load such file -- mysql)

    Wenn ihr nun aber versucht das Gem zu installieren werdet ihr mit einem Error abgespeist, der in etwa so aussieht:

    Building native extensions.  This could take a while...
ERROR:  Error installing activerecord-mysql-adapter:
	ERROR: Failed to build gem native extension.

        /usr/bin/ruby1.9.1 extconf.rb
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
	from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
	from extconf.rb:5:in `
    '


Gem files will remain installed in /var/lib/gems/1.9.1/gems/mysql-2.9.1 for inspection.
Results logged to /var/lib/gems/1.9.1/gems/mysql-2.9.1/ext/mysql_api/gem_make.out

    Und zwar benötigt ihr zum Gem installieren das Paket ruby1.9.1-dev. Neben diesem müsst ihr noch make und libmysqlclient-dev installieren sonst lauft ihr direkt in die nächsten Error Meldungen:

    apt-get install ruby1.9.1-dev make libmysqlclient-dev

    Danach könnt ihr nun wie in der ersten Meldung beschrieben das Gem mittels

    gem install activerecord-mysql-adapter

    installieren. Danach könnt ihr, wie in meiner Anleitung beschrieben, weiter machen.

    remmina: Unable to connect to RDP server

    1 Comment

    Vor ca. einem Monat bekam ich, als ich mich auf einen unserer weniger Windows Server mittels remmina verbinden wollte den Fehler Unable to connect to RDP server some.server.de. Damals war mir das egal da ich auch per ssh auf den Server kam, heute störte mich das aber und ich dachte ich guck mal was da los ist.
    Die Einstellungen auf dem Server sollten sich eigentlich im letzten Jahr nicht geändert haben, dennoch mal alles kontrolliert von iptables des Hosts bis hin zur Windows Firewall. Keine Änderungen, es sollte also gehen. Nächster Anlaufpunkt war mein PC. Also remmina mal auf der Konsole gestartet und siehe da:

    connected to some.server.de:3389
The host key for some.server.de has changed
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the host key sent by the remote host is
40:cb:0d:80:80:88:07:3b:08:d0:90:7e:c0:aa:47:3e:e1:c8:ad
Please contact your system administrator.
Add correct host key in ~/.freerdp/known_hosts to get rid of this message.
Host key for some.server.de has changed and you have requested strict checking.
Host key verification failed.
SSL_write: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.

    Ah, damit kann man doch schon mehr anfangen. Also alten Eintrag aus .freerdp/known_hosts entfernt und schon kann man sich wieder verbinden.

    Hier exisitiert auch schon ein Ticket bei Github, wo beanstandet wird das remmina den genauen Fehler nicht wiedergibt.

    Neue Interfacenamen (eth0 / em1) – biosdevname

    1 Comment

    Nachdem ich vor ein paar Tagen Ubuntu 14.04.1 installierte stellte ich zu meinem verwundern fest, das meine Netzwerkinterface plötzlich em1 und em2 hießen. Ubuntu nutzt wohl seit 14.04.1 standardmäßig die Kerneloption biosdevname, welche sich die Informationen zum benennen der Interface direkt aus dem BIOS nimmt. Für die Bezeichnung wird dann systemd Naming Schema genutzt.
    Ich seh da für mich derzeit allerdings absolut keinen Vorteil oder Mehrwert drin, sondern eher nur Verwirrung. Für mich reicht die Bezeichnung eth völlig aus und es muss für mich jetzt nicht ersichtlich sein ob es sich dabei um ein virtuelles, embedded oder pci Device handelt. Zum Ausschalten des ganzen also folgendes in die /etc/default/grub eintragen:

    GRUB_CMDLINE_LINUX_DEFAULT="biosdevname=0"

    Nachgelesen habe ich das ganze bei Redhat.