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:
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].
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
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. :)
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
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.
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:
Heute wies mich eine unserer Websites auf Arbeit mit einem Datenbank Zugriffsfehler zurück. Ich versuchte mich dann mal als root mit der Datenbank zu verbinden, wo ich die Fehlermeldung bekam das ich keine Rechte hätte auf diese zuzugreifen. Da ich das System erst letzte Woche neu gemacht hab, da das vorherige Uralt war, dachte ich erst das eines der Skripte meiner Kollegen das root Passwort geändert hat, aber selbst das alte Passwort tat es auch nicht. So startete ich dann mal die die Datenbank ohne Passwort um das root Passwort zu resetten:
mysqld_safe --skip-grant-tables &
mysql -u root
mysql> use mysql;
Allerdings bekam ich schon hier mitgeteilt das die DB mysql nicht exisitiert, also lies ich mir mal alles anzeigen, nur da war nichts. Ganz toll dacht ich mir. In der error.log von mysql stand nur folgende beiden Errormeldungen:
140827 17:54:17 [ERROR] mysql.user has no `Event_priv` column at position 29
140827 17:54:17 [ERROR] Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
Dazu fand ich nur nicht viel, nur den Hinweis das die mysql DB corrupt sein kann und das dies durch ein Update geschehen sein kann. Also mysql DB neu anlegen:
service mysql stop
rm -r /var/lib/mysql/mysql
mysql_install_db
service mysql start
Siehe da, plötzlich tauchen auch alle Datenbanken wieder auf. Nun nur wieder ein root Passwort setzen:
Am gestrigen Abend, auf der ALUG , konnte ich direkt mit meinen gestern geschriebenen Artikel, zu der Redmine Problematik unter Ubuntu 14.04, Christoph helfen sein Redmine erfolgreich aufzusetzen. Da ich in dem Artikel allerdings nur den letzten Schritt genauer beschrieben hab, welcher bei mir am längsten gedauert hat, meinte Christoph ich solle doch mal die komplette Installation in einem Artikel beschreiben, denn vor besagtem Schritt kamen noch ein paar weitere, die so nicht im Redmine.org Wiki, unter Installation aufgeführt sind. Die ersten Schritte kann man jedoch genau wie im Wiki beschrieben durchführen:
Installation von apache2 inkl. Passenger Mod und mysql-server:
Solltet ihr bei Ubuntu 14.04.2 hier in einem Fehler laufen, der euch mitteilt das ihr doch bitte den activerecord-mysql-adapter installieren sollt -> Guckt ihr hier.
Nach der Installation linken wir das public Verzeichnis von Redmine nach /var/www:
ln -s /usr/share/redmine/public /var/www/redmine
Als nächstes fügen wir in der Datei /etc/apache2/mods-available/passenger.conf hinzu:
PassengerDefaultUser www-data
In der Datei /etc/apache2/sites-available/000-default.conf folgendes ergänzen:
RailsBaseURI /redmine
PassengerResolveSymlinksInDocumentRoot on
In apache2 Version 2.4.7 liegt die Testseite nicht mehr unter /var/www/index.html sondern nun einen Ordner tiefer unter /var/www/html. Deshalb müsst ihr, wenn ihr die 000-default.conf nutzt, den DocumenRoot ändern nach:
DocumentRoot /var/www
Wenn es bei euch nicht schon während der Installation geschehen ist, müsst ihr nun noch das Passenger Modul laden und apache2 einmal neu starten:
a2enmod passenger
service apache2 restart
So laut den Anleitungen von redmine.org und ubuntuusers.com war es das nun. Ich denke aber das beide noch auf 12.04 basieren, denn soweit ich mich erinnern kann, kam da wirklich nicht mehr viel.
Ruft man nun Redmine im Browser auf, kommt eine Ruby Fehlerseite die einem mitteilt das Bundler benötigt wird. Soweit ich weiß war es bei früheren Versionen nicht nötig diesen nach zu installieren, da er bereits bei der allgemeinen Installation mit kam. Also Bundler installieren:
gem install bundler
So nun kommt man zumindest schonmal auf die Redmine Seite (Login übrigens admin admin, falls das jemand nicht wissen sollte) und auf den ersten Blick scheint auch erstmal alles zu laufen. Fängt man allerdings an Einstellungen zu tätigen oder Projekte anzulegen etc., merkt man sehr schnell das da etwas noch nicht stimmen kann, denn er wird nur einen Internal Server Error gemeldet:
Internal error An error occurred on the page you were trying to access.
If you continue to experience problems please contact your Redmine administrator for assistance.
If you are the Redmine administrator, check your log files for details about the error.
Im Log stand folgendes:
Processing by ProjectsController#new as HTML
Current user: admin (id=1)
Rendered projects/_form.html.erb (19.1ms)
Rendered projects/new.html.erb within layouts/base (23.2ms)
Completed 500 Internal Server Error in 177.2ms
ActionView::Template::Error (incompatible character encodings: UTF-8 and ASCII-8BIT):
46: <% @trackers.each do |tracker| %<
47:
51: <% end %>
52: <%= hidden_field_tag 'project[tracker_ids][]', '' %>
app/views/projects/_form.html.erb:49:in `block in _app_views_projects__form_html_erb___3771736160522816434_58407040'
app/views/projects/_form.html.erb:46:in `each'
app/views/projects/_form.html.erb:46:in `_app_views_projects__form_html_erb___3771736160522816434_58407040'
app/views/projects/new.html.erb:4:in `block in _app_views_projects_new_html_erb___2519767256062977845_56777180'
app/helpers/application_helper.rb:1042:in `labelled_form_for'
app/views/projects/new.html.erb:3:in `_app_views_projects_new_html_erb___2519767256062977845_56777180'
Er hat also irgendwelche Probleme mit inkompatiblen Kondierungen. So sieht das zumindest für mich aus. Die Recherche zeigte das hier die Änderung des MySQL Adapters in der Datei /etc/redmine/default/database.yml Besserung bringen soll. Man ändert also folgende Zeile in:
production:
adapter: mysql2
Da nur das Gem für den Adapter mysql installiert ist müssen wir nach das für mysql2 installieren. Davor müssen allerdings noch 3 Pakete nachinstalliert werden:
apt-get install libmysqlclient-dev make ruby-dev
Ob jetzt das Paket make gebraucht wird weiß ich gar nicht genau. Wenn man den Adapter über gem install installiert brauchen man ihn jedenfalls. Wir benutzen dafür allerdings Bundler, denn mit gem install mysql2 erreicht man gar nichts. Man wechselt nun in das Verzeichnis /usr/share/redmine und fügt hier am Ende der Datei Gemfile folgendes ein:
gem 'mysql2'
Im Anschluss führt man in dem Verzeichnis
bundle update
aus, welches dann das mysql2 Gem installiert. Nun startet man noch einmal den apache2 neu und schon ist es geschafft. Redmine sollte nun laufen.
Ich habe gerade ein neues Redmine aus dem PPA ppa:ondrej/redmine installiert, welches auch nach der Installation erstmal zu laufen schien. Wollte man jedoch z.B. ein neues Projekt anlegen oder an der Konfiguration rummstellen, bekam man die für Redmine typische Seite, wenn man etwas falsch konfiguriert hat. Im Log sagte er mir folgendes:
Processing by ProjectsController#new as HTML
Current user: admin (id=1)
Rendered projects/_form.html.erb (19.1ms)
Rendered projects/new.html.erb within layouts/base (23.2ms)
Completed 500 Internal Server Error in 177.2ms
ActionView::Template::Error (incompatible character encodings: UTF-8 and ASCII-8BIT):
46: <% @trackers.each do |tracker| %>
47: <label class="floating">
48: <%= check_box_tag 'project[tracker_ids][]', tracker.id, @project.trackers.include?(tracker), :id => nil %>
49: <%=h tracker %>
50: </label>
51: <% end %>
52: <%= hidden_field_tag 'project[tracker_ids][]', '' %>
app/views/projects/_form.html.erb:49:in `block in _app_views_projects__form_html_erb___3771736160522816434_58407040'
app/views/projects/_form.html.erb:46:in `each'
app/views/projects/_form.html.erb:46:in `_app_views_projects__form_html_erb___3771736160522816434_58407040'
app/views/projects/new.html.erb:4:in `block in _app_views_projects_new_html_erb___2519767256062977845_56777180'
app/helpers/application_helper.rb:1042:in `labelled_form_for'
app/views/projects/new.html.erb:3:in `_app_views_projects_new_html_erb___2519767256062977845_56777180'
Damit konnte ich erstmal nix anfangen. Ich seh das er irgendwelche Probleme mit den Kodierungen hat, das wars aber auch schon. Nach kurzer Suche bei Google war die Lösung gefunden – den Datenbank Adapter unter /etc/redmine/default/database.yml von mysql in mysql2 ändern. Das kam mir sogar noch aus vorherigen Redmine Installationen bekannt vor. Nachdem das geändert wurde, musste nun natürlich auch noch das entsprechende Ruby Gem installiert werden:
apt-get install libmysqlclient-dev make ruby-dev
gem install mysql2
Die Pakete libmysqlclient-dev make und ruby-dev musste ich noch vorher installieren, sonst schlug die Installation des Ruby Gem’s fehl. Danach startete ich den apache2 neu und nun verlangte er das nächste Gem und zwar activerecord-mysql2-adapter. Also das auch noch installiert, apache2 Neustart und…..er will immer noch dieses Gem haben. Die Fehlermeldung sah wie folgt aus:
Please install the mysql2 adapter: `gem install activerecord-mysql2-adapter` (cannot load such file -- mysql2)
Nachdem ich dann eine ganze Weile rummprobiert und gesucht habe fand ich die Lösung.
Also die beiden Gems erstmal wieder deinstalliert: