Tag: software

normalerweise nutzt man den befehl ssh-copy-id so:

ssh-copy-id -i path/my_id_rsa.pub user@host.tld 

wenn der zielserver allerdings einen vom standard (22) abweichenden port nutzt, dann kann es mit aelteren versionen des ssh-copy-id befehls probleme mit dem “-p” parameter geben. dann ist dieser mit dem hostnamen in hochkommata zu setzen:

ssh-copy-id -i path/my_id_rsa.pub "user@host.tld -p 19022"

igendwie meckert mein owncloud client immer rum, dass er nicht aktuell waere. scheinbar funktioniert das updaten mit den “normalen” repositories nicht so dolle. kurz meinen freund G. befragt, was gefunden, ausprobiert, funktioniert! damits nicht verloren geht, nochmal hier:

wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_14.04/Release.key
sudo apt-key add - < Release.key
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"
sudo apt-get update
sudo apt-get install owncloud-client

manchmal sucht man einfach zuviel und die loesung ist so einfach. der mitgelieferte scansnap manager beim fujiitsi ix500 ist ja schoen einfach und ganz nett gehalten. ich habe aber die ganze zeit eine option gesucht, dass nach dem scannen einfach die PDF datei mit vorgegebenen einstellungen gespeichert wird. dazu muss natuerlich erstmal das gewuenschte dateinamenformat angepasst werden.

und dann bei der zu oeffnenden anwendung “Keine” ausgewaehlt werden. da lag bisher mein fehler, dass ich da irrtuemlicherweise “scan to folder” ausgeaehlt hatte. das fuerht dazu, dass ein speichern dialog aufgeht. aber nun wird der scan einfach gespeichert ohne, dass man noch irgendeinen button druecken muss 😉

im linux mint 17.3 repository findet sich momentan nur ein alter owncloud desktop client (1.5.0). wenn man versucht, sich damit an einer aktuellen owncloud installation anzumelden, bekommt man nur die fehlermeldung “Wrong Crendentials”.

um einen aktuellen owncloud client zu installieren muss man die datei /etc/apt/sources.list.d/owncloud-client.list (ggf. anlegen und) mit folgendem inhalt fuellen:

deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /

danach diese befehle ausfuehren:

sudo apt-get update
sudo apt-get install owncloud-client

wenn beim “apt-get update” ein fehler kommt bezueglich eines fehlenden keys mit der ID 977C43A8BA684223, dann kann man diesen wie folgt hinzufuegen:

gpg --keyserver pgpkeys.mit.edu --recv-key 977C43A8BA684223
gpg -a --export 977C43A8BA684223 | sudo apt-key add -

…danach nochmal die obenstehenden apt befehle ausfuehren

kb3053711 bei microsoft bescchreibt was gaaaaanz geiles:

Symptoms
In Windows 8.1, when the user account name contains the word “user”, intermittently you will find the process taskhost.exe keeps consuming high CPU percentage.
[…]
Resolution
To resolve the issue, do not create a user account contains the string “user” on the computer.

made my day… aber sowas von

noch eine nummer einfacher als meine bisherige beschreibung:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout 'domain_tld.key' -out 'domain_tld.csr' -subj '/CN=domain.tld/C=DE'

man soll es kaum glauben, aber es gibt heute immernoch software, die scheinbar nicht mit leerzeichen im installationspfad zurecht kommt. generell finde ich leerzeichen ja auch doof, aber technisch ist das heute keine herausforderung mehr. oracle will wirklich keine leerzeichen im verzeichnisnamen…:

und! auch sehr geil.. braucht zur installation auf einem windows rechner die standardfreigabe C$ fuer den zugriff auf einen temporaeren ordner.

2016!

was manche hersteller heute (2016!) noch in ihre software einbauen… unglaublich. bei einem dieser mistigen programme kann man beim setup z.b. “ODBC and Access Support” auswaehlen, was wohl den zugriff auf irgendwelche datenbanken erlauben soll. eigentlich fand ich den beschreibenden hinweis ganz nett:

“These Components are probably already on your system, but there is no harm in checking”

… schadet also nix sollte man meinen.

aber was dann damit ins windows/system32 verzeichnis installiert wird, laesst die kinnlade erstmal runter klappen:

dll’s usw. aus dem jahre 1996… darunter ne vba runtime 3.0.. au backe. das mag ich schon als grob fahrlaessig bezeichnen.

mein opsview hat die tage wieder mal gestreikt. ich erinnerte mich, doch irgendwo schonmal was aufgeschrieben zu haben. in den entwuerfen meines blogs bin ich fuendig geworden. wie man am datum der logeintraege sehen kann, ists schon ein paar tage her. ich hab das ganze mal aktualisiert und voila.. da isses:

####

heute morgen hat mein nagios bzw. opsview seinen dienst quittiert. im logfile waren solche eintraege zu finden:

[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796429.397065 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796429.397065
[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796433.896315 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796[2015/04/12 07:38:50] [nrd] [WARN] 2015/04/12-07:38:50 Server closing!

ok, die mysql datenbank ist 22GB gross und die tabelle ‘nagios_servicechecks’ hat rund 60 millionen eintraege. was der limitierende faktor war, konnte ich auf die schnelle nicht rausfinden. normalerweise sollten in dieser tabelle nur daten von einer woche vorgehalten werden. also in mysql den befehl ausfuehren:

DELETE FROM nagios_servicechecks WHERE start_time <= '2014-07-01 00:00:00';

ursache: fehlende cronjobs! bei der letzten migration auf einen anderen server sind die entsprechenden crontab eintraege fuer den nagios user "verloren" gegangen.
dieser cronjob sollte fuer den user nagios eingerichtet sein:

11 4 * * * . /usr/local/nagios/bin/opsview_master_housekeep

aus “seo gruenden” wegen pagerank und performance und so werden gerne bilder von einer anderen oder einer subdomain ausgeliefert.
wie man das mit einfachen mitteln mit wordpress macht, beschreibe ich hier.

frueher gabs in wordpress in den einstellungen unter “media” diese beiden werte:

mit irgendeiner version verschwanden diese aus der gui. um diese trotzdem wieder zu setzen, kann man sich unterschiedlicher methoden bedienen. man kann z.b. ein plugin wie “WP Original Media Path” nutzen, welches diese beiden felder wieder herstellt. das plugin kann man nach dem setzen wieder deinstallieren.

oder aber man setzt einfach diese beiden werte in der datenbank in der “options” tabelle:

weiterhin muss man noch einen neuen vhost im webserver anlegen. im beispiel ist es “img.sd.vc”. das document root dieses vhosts ist identisch mit dem der wordpress installation plus dem verzeichnis “wp-content/uploads“. wenn das document root der wordpress installation also “/var/www/domain.tld/” ist, dann ists fuer den vhost fuer die media dateien “/var/www/domain.tld/wp-content/uploads/”

da diese einstellungen nur bei neuen posts und pages greifen, funktioniert das wordpress erstmal weiter wie gehabt. um die alten eintraege anzupassen, muss man die image urls direkt in der datenbank aendern. ein beispiel hier:

UPDATE wp_posts SET post_content = REPLACE(post_content,'https://www.domain.tld/wp-content/uploads/','https://img.domain.tld/')

das wars.. garnicht so schwer 😉