Tag: software

Tools -> Options -> LibreOffice -> Advanced -> (Button) Expert Configuration

Preference “/org.openoffice.Office.Common/History”
Value “PickListSize” -> 0

endlich mal fett storage fuer die eigenen server….

nee.. mal im ernst. ich hab mich die letzte zeit ein wenig mit ceph beschaeftigt und habe auch ein funktionierendes setup mit mehreren nodes hingestellt. wenn ich mal mehr zeit habe, schreibe ich hier sicherlich nochmal ein wenig darueber.
aber ceph… ich muss schon sagen… “da geht mir voll einer ab dabei”. ich liebe diese technik.

irgendwann – ich weiss nicht mehr wann und “nach was” – wurde mir auf meinem laptop das owncloud icon in der system tray nicht mehr angezeigt. nach viel googlen und merkwuerdigen und veralteten forenbeitraegen war die leosung dann doch viel einfacher als gedacht. auch wenn ich den grund fuer das verhalten (noch) nicht kenne und die loesung etwas komisch finde…. ach… will ich gerade auch garnicht wissen. so kriegt man es geloest:

(aktuell linux mint 18.1 cinnamon und owncloud client 2.3.3)

“system settings” -> “startup applications” ….schaut so aus:

dann die einstellungen fuer owncloud aendern und ein paar sekunden “startup delay” einbauen:

that’s it. nach einem neustart erscheint das tray icon dann wieder 🙂

nach einer frischen linux mint installation habe ich den psi+ nicht zum laufen bekommen. bei der auswahl, dass immer ssl verwednet werden soll, wurde gemeckert, dass ein plugin fehlt. nach langer recherche hab ichs auch gefunden… naemlich das: libqca2-plugins-ossl
einfach ueber den package manager nachinstallieren und gut

nach dem letzten owncloud update konnte ich die calendar app nicht mehr hinzufuegen. die meldung “Signature could not get checked. Please contact the app developer and check your admin screen” stand geschrieben.. ein blick ins admin panel beim integrity check ergab das:

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- calendar
	- EXCEPTION
		- OC\IntegrityCheck\Exceptions\InvalidSignatureException
		- Certificate has been revoked.
Raw output
==========
Array
(
    [calendar] => Array
        (
            [EXCEPTION] => Array
                (
                    [class] => OC\IntegrityCheck\Exceptions\InvalidSignatureException
                    [message] => Certificate has been revoked.
                )

        )

)

bei github konnte man nachlesen, das irgendwer irgendjemandes zertifikat revoked hat. um die app doch zu installieren, kann man temporaer (!) diese zeile in die config.php einfuegen:

'integrity.check.disabled' => true

…damit klappts dann.

mir wurde die ehre zuteil, auf einem uralten server mit debian etch proftpd mit mysql support fuer die userdb zu konfigurieren. nur leider wollte das ums verrecken nicht funktionieren. beim login versuch kam im logfile immer nur:

FTP session requested from unknown class

lange gesucht, aber doch noch gefunden…

When you get a message saying “FTP session requested from unknown class” on Debian Etch 4.0 (ProFTPD Version 1.3.0) and you are trying to use MySQL authentication, this is probably due to the

LoadModule mod_sql_postgres.c

in /etc/proftpd/modules.conf file, which line should be commented out. I see this as a bug in the proftpd package, since I have NOT installed the proftpd-pgsql package, so this line should not be present, and also, at least it shouldn’t affect the work of the proftpd-mysql package, which is successfully installed.

was eine alte hundekacke. auskommentiert und gut.

was frueher extreme schmerzen bereitet hat, ist mit otrs5 fast ein kinderspiel. standardmaessig speichert otrs anhaenge mit in der datenbank. wenn man zu supportzwecken o.ä. oefters screenshots und andere anhaenge geschickt bekommt, waechst die datenbank schnell. das geht auf die performance und macht das backup unangenehm.

umstellen auf speicherung der anhaenge im dateisystem geht denkbar einfach. in der “SysConfig” einfach diese Einstellung von ArticleStorageDB auf ArticleStorageFS umstellen:

das gilt aber dann nur für neue tickets. um die bestehenden anhaenge aus der datenbank ins filesystem zu bekommen muss man diesen befehl ausfuehren:

otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

der standard speicher pfad fuer die anhaenge ist “/var/article”, welchen ich in meinem fall aus dem otrs verzeichnis ausgelagert habe, da es sonst bei jedem update mit meinem eigenen vorgehen “kollidiert”. die passende einstellung “ArticleDir” findet man in der SysConfig an der gleichen stelle.

diese nepper, schlepper, bauernfaenger von 1&1… da surft man auf deren seite rum – mit dem aktuellsten firefox, den es gerade gibt – und dann blenden die einem sowas ein:

und was kriegt man da? einen mit spy-, bloat-, ransom-, wasweissichwas -ware “gepimpten” firefox, der mit sicherheit total verbogen ist und alles was nur geht mit 1&1 vorkonfiguriert hat. bei sowas krieg ich nen hals. haben die es echt noetig, solche methoden anzuwenden? ich rege mich bestimmt gerade nicht das erste mal darueber auf.
aber natuerlich machen die das alles nur im interesse ihrer kunden… is klar.

unter linux stehen diese informationen in /proc/cpuinfo geschrieben. da dann in einer zeile auch gleich mal >50 sogenannte “flags” stehen, wirds schnell unuebersichtlich.

konkret sind es diese beiden, die uns interessieren koennten:

vmx – Intel VT-x virtualization support enabled in BIOS
svm – AMD SVM virtualization support enabled in BIOS

klar kann man das muehsam durchsehen oder mit “grep –color” den gewuenschten wert farblich hervorheben.. aber irgendwo hab ich mal nen einzeiler gefunden, der das ganze auch noch schick aufbereitet.

egrep -wo 'vmx|svm|lm|aes' /proc/cpuinfo | sort | uniq | sed -e 's/lm/64 bit CPU = Yes (&)/g' -e 's/vmx/Intel VT-x virtualization = Yes (&)/g' -e 's/svm/AMD SVM virtualization = Yes (&)/g'

(den 64 bit support gibts auch gleich mit aus)
das ergebnis schaut z.b. so aus:

es kommt doch vor, dass man steinalte linux installation hueten muss.. 😉
wenn der ssh client zu alt ist fuer die ssh server, stolpert man ueber diese meldung:

no kex alg

dann muss man am ende der datei /etc/ssh/sshd_config diese zeile einfuegen und den sshd neu starten:

KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

das sind alte ciphers, die irgendwann mal standardmaessig bei opsenssh rausgeschmissen wurden und als “potentially-incompatible changes” deklariert sind.