Dag allemaal,
openSUSE 13.2 is dus ter wereld. Voor iedereen verkrijgbaar. Post hier je ervaringen, tips voor anderen.
Om meteen maar even van wal te steken:
Als je een NVIDIA Optimus laptop hebt ( met een Intel grafische kaart/chip én een NVIDIA kaart ) kun je rare fenomenen krijgen, zowel in KDE als in GNOME. De kortste klap is om ondanks alles toch de systeeminstellingen te starten en onder het kopje Scherm / Monitor te kijken, en daar het tweede (VGA) scherm uit te schakelen. Ik ben nog aan het uitzoeken in welke config bestanden dit staat, zodat ik er een bug voor kan rapporteren.
Voor het overige: KDE is KDE, maar dan nog weer wat netter, nog meer interessante en minder interessante features, en voor mij is KDE thuis, maar GNOME is sinds ik 't een jaar gebruikt heb enorm vooruit gegaan. Vlot, vloeiend, rustig, komt zeer stabiel over.
Tumbleweed, de nieuwe rolling release waarvan gisteren de iso is vrijgegeven, idem. Dit kon inderdaad wel eens een top release zijn.
Heb het ook in een andere draadje aangegeven, maar misschien is het hier meer op z’n plek.
Als je een systeem hebt met AMD videokaart, en je wilt niet de open-source drivers gebruiken, kun je beter nog even bij 13.1 blijven.
De fglrx drivers zijn niet beschikbaar voor 13.2 (en/of Rolling)
Ik persoonlijk heb het een beetje gehad met AMD maar goed, het zit nu eenmaal in mijn computer.
Er is blijkbaar een bug bij AMD
Voor informatie:
https://lizards.opensuse.org/tag/fglrx/
Wat betreft Tumbleweed, deze heb ik op een laptop staan met INTEL hardware.
Dat werkt perfect (uiteraard zal 13.2 daar ook goed op werken)
Al met al, mijn complimenten voor het openSUSE team.
Grappig, mijn stagiair was hier tegenaan gelopen. Werkte keurig zijn 13.1 lijstje af, horhgh geen fglrx driver. En nu is zijn vraag waar dat ding goed voor is. Zelfs Google Earth draait bij hem (ik weet even niet wat voor AMD/ATI hij heeft) op de open source driver.
Ik gebruik die computer ook voor gamen.(Steam)
Hoewel de open source driver helemaal niet slecht is, gaat een game als “Metro” of “borderlands 2” echt niet lukken.
Vanmiddag op 2 laptops 13.2 geïnstalleerd. lijkt goed te werken. ook lekker vlot op een netbook.
1 probleempje. Installatie van Kdeconnect (widget voor Android op bureaublad) laat Plasma crashen. Continu,dus die voorlopig weer verwijderd.
Nu nog de rest uitproberen. Op mijn lijstje: 2 schermen met laptop, virtualbox, xbmc, mythtv.
Ik heb zelfs op mijn hoofdcomputer 13.2 geïnstalleerd. Helaas werkt deze versie nog niet vlekkeloos. Graag wat hulp waar ik moet zoeken om e.e.a. uit te sluiten.
Op zowel mijn netbook als mijn hoofdcomputer loopt plasma vast. Ik heb op t Engelse forum een topic gevonden wat mij leek te passen met mijn ervaring. Linkje “KDE4.14.2 Isn’t stable”. Mijn beide computers hebben verschillende videokaarten.
Verder blijft MariaDB melding geven dat bij starten iets verkeerd gaat: “Starting service MySQL Something went wrong”. Ik heb in de log al fouten in de database gevonden. Met
MyIsamCheck -r -q *.MYI
heb ik de databases kunnen repareren. In de log kan ik niet vinden waarom die melding blijft staan. De database lijkt verder wel te werken.
Positieve ervaring: Mythtv was voorheen altijd lastig installeren door de combinatie Yast en Mythtv. TVkaart in Yast instellen, Mythtv-setup gebruiken om ook van alles in te stellen.
Maar nu ging de installatie heel vlot. Nu de database werkt, zijn de instellingen voor Mythtv nog beschikbaar. De setup past de databasetabellen aan naar een nieuwe versie voor Mythtv. Na controle andere instellingen kon ik zo maar het vragenuurtje van de Tweede kamer volgen. Snel na 2 minuutjes weer uitgezet. 
Verder moet ik wennen aan de vele linkjes voor btrfs op de root-partitie. Voor de hoofdcomputer ben ik nu over op btrfs. Op de netbook was ik dat al eerder.
Snapper geeft met Btrfs ook een uitdaging om genoeg ruimte te houden op je root-partitie van 20 Gb. Daarvoor inmiddels bij alle pc’s de standaardinstellingen gewijzigd. Standaard staat ‘alles’ op 10 en volgens mij loopt er geen automatische Snapper cleanup. Nu heb ik met
snapper set-config TIMELINE_LIMIT_HOURLY=3
snapper set-config TIMELINE_LIMIT_HOURLY=4
hier wat minder van gemaakt.
Om te controleren er een beetje ruimte overblijft gebruik ik nu een paar van deze commando’s:
btrfs fi show
btrfs fi df /
btrfs sub list /
Respectievelijk om te kijken of de SSD genoeg ruimte heeft; of er genoeg vrije blokken zijn om nog uit te breiden en sub list om naar het aantal snapshots te kunnen kijken. Die laatste vind ik makkelijker, geeft minder tekst, dan Snapper list. Verder in Cron twee keer Snapper cleanup ingesteld, voor timeline en voor number.
Met Btrfs heb ik leren werken door mijn telefoon van Jolla. Die heeft ruimtetekort en reboot daardoor. Jolla draait standaard geen btrfs balance. OpenSUSE doet dat wel.
Wat betreft de AMD drivers, is er een oplossing.
(heb het zelf nog niet uitgeprobeert)
http://forums.opensuse.org/showthread.php/502138-Anybody-managed-to-get-fglrx-on-13-2-yet/page2
Hieronder wat ervaringen - geen problemen.
Mijn systeem is 4 jaar oud en heeft een ouderwetse BIOS/MBR. Alle geïnstalleerde systemen zitten in logische partities.
Intussen heb ik twee installaties van 13.2. De eerste is bedoeld om kennis te maken en van alles te proberen. Hier heb ik geen aparte /home aangemaakt, het filesysteem is ext4. Nog geen enkel probleem tegengekomen.
De tweede installatie is bedoeld om kennis te maken met Btrfs en Xfs. Meteen al een probleem: de eerste boot, nog in het installatieproces, lukte niet. Een advies op het forum volgend heb ik toen opnieuw geïnstalleerd, maar nu met een aparte (derde) ext2 partitie voor /boot; grootte 250 MB. Dit liep probleemloos. Omdat ik voorlopig mijn 13.1 systeem blijf gebruiken heb ik dat geboot (vanuit 13.2) en toen met grub2-mkconfig en grub2-install dit systeem weer de eerste optie in het Grub menu gemaakt. Merkwaardig genoeg komt in dit Grub menu het 13.2-btrfs systeem niet voor. Het is kennelijk niet herkend door Grub2 van 13.1.
Dit is allemaal een beetje academisch, want ik ben voorlopig niet van plan over te gaan op btrfs.
Samengevat: zover zo goed.
Nog meer ervaringen:
- Printer Canon MG6150 snel gedetecteerd.
- Scanner Canon MG6150 ook snel gedetecteerd. Eerste test met XSane werkte prima. Later wil XSane ogenschijnlijk niet opstarten. Pas bij uitzetten van de printer wordt XSane actief. Scannen lukt niet meer.
- Printen vanuit LibreOffice levert de halve tekst op een A4. Eerst de linkerhelft, daarna de rechterhelft. Grappig gezicht, maar wat t is snap ik niet. Instellingen, marges, printvoorbeeld, van alles bekeken. Niet direct iets zichtbaar wat t probleem oplost.
- Printen van een PDF vanuit Okular lukt op 1 A4.
- Owncloud 7 installatie lukt prima. Maar migreren van Owncloud 5 lukte niet. Natuurlijk heb ik een backup en heb de migratie van de ownclouddatabase door Owncloud uiteindelijk opgegeven. Owncloud 5 terug gezet. Contacten en Agenda geëxporteerd respectievelijk in .VCF en . ICS. Daarna kun je in Owncloud de .VCF weer importeren. De .ICS heb ik in Kontact geïmporteerd. Daarvoor wel eerst in de Systeeminstelling | Persoonlijke informatie | Akonadi hulpbronnenconfiguratie een nieuwe DAV groupware resource
aangemaakt (en de oude owncloud verwijderd. Daarna synchroniseren had bij mij wel wat tijd nodig met 1136 items. - Kopete lijkt niet meer te willen verbinden met (voorheen) MSN en ICQ. - Mail werkte niet. Resultaten van de cron jobs kwamen niet in de systemmail. Ik ben even kwijt wat ik precies heb gedaan. Iets met rechten op de postfix. Daarna doet Mail t wel. Backups in Cron zijn nu terug te vinden in de Mail.
Ik moet even kwijt dat ik, als jarenlang KDE gebruiker, enorm onder de indruk ben van de GNOME van openSUSE 13.2 . Ja, de interface is kompleet anders, en toch zie ik er mensen zo “op weg fietsen”.
Dus zelf ook maar weer 's de proef op de som genomen, en in een schoon gebruikersaccount een deel van mijn “gewone” account opgezet. Wat mapjes kopiëren, accounts aanmaken (lekker helder op één plek) en het werkt. Bijvoorbeeld mijn eigen owncloud account. Ingevoerd en opeens kan ik het icoon “Documenten” gebruiken en direct in de cloud werken. E.e.a. komt daarbij bij mij ook nog 's superverzorgd over, is supersnel en zonder mankeren op de Intel GPU in mijn laptop. Omdat ik al een paar online accounts had opgezet, startte Evolution meteen met het binnenhalen/syncen van mail/agenda’s etc. De komende weken maar 's kijken of ik 't niet zo kan krijgen dat ik in KDE/Kontact én GNOME/Evolution kan werken én ook nog 's beide in sync kan houden. Moet kunnen, ik heb alleen maar IMAP- en owncloud accounts. Dan misschien maar weer 's een maandje GNOME draaien, kijken of ik mijn workflow en verder gebruik ook met GNOME apps kan doen.
Ja, Gnome is prachtig geworden.
Vooral de online mogelijkheden zijn geweldig.
Wel vind ik het een probleem dat we programma’s van derden moeten gebruiken om Gnome gebruikersvriendelijk te maken.
Minimaliseer knop kan alleen door middel van tweaktool.
En de meeste mensen die ik ken en Gnome gebruiken hebben allemaal wel een paar extensies.
Een simpel paneel verzetten kan nog steeds niet.
Ik kan KDE veranderen in Gnome, maar Gnome niet in KDE (als voorbeeld)
Als je Gnome niet leuk vind, kun je het niet aanpassen naar je eigen voorkeuren.
(als je bv mijn KDE desktop zou zien, die lijkt in de verste verte niet op de “basis” KDE)
Maar toch vind ik Gnome steeds beter worden, en gebruik het ook steeds vaker.
Ik ben zelf een KDE gebruiker, maar ik heb de screenshots van de nieuwe GNOME gezien en het ziet er inderdaad heel gelikt uit.
Wat ik wel merkte tijdens het installeren van 13.2 (doe een verse installatie vanaf een USB-stick)
Dat het automatisch partioneren niet helemaal goed gaat.
Het programma probeert mijn USB-stick te gebruiken om openSUSE op te installeren.
Uiteraard kan men dit handmatig aanpassen, maar toch een beetje vreemd.
Dat lijkt me iets BIOS achtigs. Heb 't wel eens gezien, ook wel dat GRUB in de MBR van de stick terecht kwam. Maar ik kan me alleen herinneren dat ik dan iets in de BIOS setup veranderde en het daarna wel goed ging.
Kan niet echt iets vinden in het Bios dat daar invloed op heeft.
Heb 13.1 even geprobeerd, en die doet het wel goed.
Meer ervaringen: Eerder meldde ik mijn ervaring met “Mail werkt niet”. Ik heb 13.2 opnieuw geïnstalleerd en weer werkt de mail niet. Nu heb ik e.e.a. beter uitgezocht.
De oplossing staat op t Engelse forum, hier: Problems with Email from Cron job.
Ik verwacht mail te krijgen na een Cron-job. Iedere nacht laat ik wat opdrachten uitvoeren, zoals een backup van diverse directories en de inhoud van mijn telefoon. Met het commando “mail” in de konsole zie je wat het resultaat is van die cron-job. Het commando “mail” gaf echter “No mail for max”.
In de log vond ik meldingen die hielpen om te begrijpen dat de mail niet werd afgeleverd. Zie:
cron[2328]: postdrop: warning: mail_queue_enter: create file maildrop/598616.9826: Permission denied
postfix/postfix-script[2263]: warning: not owned by group maildrop: /usr/sbin/postqueue
Ik moet wel wennen aan het gebruik van journalctl. Een paar tips voor lezen van de logging:
journalctl
journarctl -u cron
journalctl -u postfix
journalctl -e
Respectievelijk: Journal log laten zien, alleen van cron de logging laten zien, alleen van postfix laten zien, naar het einde van de logging springen.
Gemaakt:
postfix/local[9880]: 24F6A271: to=<max@systeem.domein>, orig_to=<max>, relay=local, delay=303, delays=303/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Zoals in Problems with Email from Cron job gemeld, heb ik op /usr/sbin/postdrop de rechten van de groep maildrop geplaatst. Zoals hier:
# chgrp maildrop /usr/sbin/postdrop
# chmod g+s /usr/sbin/postdrop
# ls -l /usr/sbin/postdrop
-rwxr-sr-x 1 root maildrop 15008 25 sep 20:13 /usr/sbin/postdrop
Ik heb dit wat uitgebreid gedocumenteerd. Zodat ik bij de volgende installatie e.e.a. kan terugvinden. En ik hoop dat t jullie ook helpt.
Dank je wel:
mail knurpht
Subject: Oja, Max weet dit
maildrop group to /usr/sbin/postdrop AND chmod g+s
.
EOT
geeft nu netjes
mail -u knurpht
Heirloom mailx version 12.5 7/5/10. Type ? for help.
"/var/mail/knurpht": 1 message 1 new
>N 1 root@laptop.knurph Mon Dec 15 17:04 18/618 Oja, Max weet dit
?
Message 1:
From root@laptop.knurpht Mon Dec 15 17:04:11 2014
X-Original-To: knurpht
Delivered-To: knurpht@laptop.knurpht
Date: Mon, 15 Dec 2014 17:04:11 +0100
To: knurpht@laptop.knurpht
Subject: Oja, Max weet dit
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: root@laptop.knurpht (root)
maildrop group to /usr/sbin/postdrop AND chmod g+s
?
Meer ervaringen met journalctl:
Ik weet niet of dit specifiek opensuse 13.2 is, maar het valt mij nu pas op. Ik heb nu tijd. 
Met journalctl -e kun je in je logging direct naar t einde springen. en met journalctl -f volg je de actuele logging. Mij valt op dat ik heel veel opmerkingen zie over autorisatie en over pogingen op iets met ssh te doen. Daar wil ik van af!
Nu, dat kan met fail2ban. Dus die heb ik ook even ingesteld. Zie fail2ban.org
Hoe werkt het?
In de update-repo zit al een package voor fail2ban versie 0.8.4. Helaas werkt deze versie alleen met rsyslog en /var/log/messages. Pas vanaf versie 0.9 werkt fail2ban met systemd, las ik. Ik veronderstel dat dan pas echt met journalctl kan worden gewerkt.
De logging vertelt dit (en dit gaat dag en nacht door, tig pogingen per minuut):
dec 17 00:00:51 monch sshd[20425]: error: PAM: Authentication failure for root from 208.43.121.163-static.reverse.softlayer.com
dec 17 00:00:51 monch sshd[20425]: Received disconnect from 208.43.121.163: 11: Bye Bye [preauth]
dec 17 00:00:52 monch sshd[20617]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=208.43.121.163-static.reverse.softlayer.com user=root
dec 17 00:00:54 monch sshd[20615]: error: PAM: Authentication failure for root from 208.43.121.163-static.reverse.softlayer.com
dec 17 00:00:54 monch sshd[20615]: Received disconnect from 208.43.121.163: 11: Bye Bye [preauth]
dec 17 00:00:54 monch kernel: SFW2-INext-ACC-TCP IN=enp3s0 OUT= MAC=00:24:1d:7d:e7:bd:cc:5d:4e:0a:8c:7b:08:00 SRC=208.43.121.163 DST=192.168.1.10 LEN=60 TOS=0x00 PREC=0x00 TTL=180 ID=34781 DF PROTO=TCP SPT=55226 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A35E8A9440000000001030307)
dec 17 00:00:55 monch sshd[20620]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=208.43.121.163-static.reverse.softlayer.com user=root
dec 17 00:00:57 monch sshd[20618]: error: PAM: Authentication failure for root from 208.43.121.163-static.reverse.softlayer.com
dec 17 00:00:57 monch sshd[20618]: Received disconnect from 208.43.121.163: 11: Bye Bye [preauth]
Na installatie van fail2ban via Yast - Softwarebeheer zul je zelf je instellingen moeten maken. Het beste doe je dat in het bestand jail.local. Daar zet je elementen in van het bestand jail.conf. Voordeel is dat bij een nieuwe installatie vanuit Softwarebeheer je instellingen worden bewaard. Alle bestanden staan in /etc/fail2ban. Als root pas je jail.local aan naar je wensen. Vul true in bij de secties die je wil gebruiken, voorbeeld met drie secties:
# This jail corresponds to the standard configuration in Fail2ban.
# The mail-whois action send a notification e-mail with a whois request
# in the body.
[pam-generic]
enabled = true
filter = pam-generic
action = iptables-allports[name=pam,protocol=all]
logpath = /var/log/messages
[xinetd-fail]
enabled = false
filter = xinetd-fail
action = iptables-allports[name=xinetd,protocol=all]
logpath = /var/log/daemon*log
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=max, sender=fail2ban@monch.alpen, sendername="Fail2Ban"]
logpath = /var/log/messages
maxretry = 5
Daarna start je de fail2ban.service:
# systemctl start fail2ban.service
Denk er ook aan deze zo in te stellen (bijvoorbeeld in Yast Servicesbeheerder) dat bij een reboot de service ook start.
De status ziet er dan zo uit, met wat waarschuwingen. Het werkt wel:
# systemctl status fail2ban.service -l
fail2ban.service - Bans IPs with too many authentication failures
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled)
Drop-In: /usr/lib/systemd/system/fail2ban.service.d
└─SuSEfirewall2.conf
Active: active (running) since wo 2014-12-17 13:17:26 CET; 1h 33min ago
Process: 13665 ExecStart=/usr/bin/fail2ban-client -x $FAIL2BAN_OPTIONS start (code=exited, status=0/SUCCESS)
Main PID: 13668 (fail2ban-server)
CGroup: /system.slice/fail2ban.service
└─13668 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x
dec 17 13:17:24 monch fail2ban-client[13665]: WARNING 'actioncheck' not defined in 'Definition'. Using default one: ''
dec 17 13:17:24 monch fail2ban-client[13665]: WARNING 'actioncheck' not defined in 'Definition'. Using default one: ''
dec 17 13:17:25 monch fail2ban-client[13665]: 2014-12-17 13:17:25,693 fail2ban.server [13666]: INFO Starting Fail2ban v0.8.14
dec 17 13:17:25 monch fail2ban-client[13665]: 2014-12-17 13:17:25,693 fail2ban.server [13666]: INFO Starting in daemon mode
Zoals je in het bestand jail.local kan zien, werkt fail2ban nu met /var/log/messages. Die logging kun je terugkrijgen door rsyslog te installeren. Ik vind dat ik wel kan wachten tot versie 0.9.1 in een package voorbij komt. Toch heb ik nu een tekstbestand nodig die messages heet waar een deel van de logging in staat. Die maak ik uit de journalctl.
Waarom? Na het maken van een bestand messages wordt het ip-adres tijdelijk geblokkeerd. Vervolgens zie je dat ip-adres niet meer terug in de logging. Werkt dus goed genoeg met af-en-toe wat handwerk. Zou ook automatisch kunnen met een cron job.
# journalctl -o short --since "2014-12-17 13:00:00"
Je kan op twee manieren nu een /var/log/messages aanmaken. Handmatig door de toets S in te drukken, of automatisch. Voorbeeld van het laatste:
# journalctl -o short --since "2014-12-17 13:00:00" > /var/log/messages
Let op, de commando’s als root.
Andere commando’s die ik nu heb geleerd. Kijk met de fail2ban-client wat de status is. Of hoeveel nu (in een jail) is geblokkeerd. Het voorbeeld verteld NUL omdat, sja, het werkt!
# fail2ban-client status ssh-iptables
Status for the jail: ssh-iptables
|- filter
| |- File list: /var/log/messages
| |- Currently failed: 0
| `- Total failed: 0
`- action
|- Currently banned: 0
| `- IP list:
`- Total banned: 0
Of handmatig een ip-adres blokkeren. Omdat je toch aan t kijken bent in je logging en je er direct van af wil. Het ip-adres wordt dan de defaulttijd geblokkeerd (600 seconden).
# fail2ban-client set ssh-iptables banip 208.43.121.163
De status veranderd weer:
# fail2ban-client status ssh-iptables
Status for the jail: ssh-iptables
|- filter
| |- File list: /var/log/messages
| |- Currently failed: 0
| `- Total failed: 5
`- action
|- Currently banned: 1
| `- IP list: 208.43.121.163
`- Total banned: 1
Voor de gewone installatie ben je klaar. Ik heb laten zien dat fail2ban werkt.
Toch wil ik meer. Ik heb ervaring dat op den duur een ip-adres toch wel weer eens kan aankloppen. Dus ben ik ook op zoek gegaan naar permanente ban van een ip-adres. Ik heb deze beschrijving bij een mijnheer Phil Hagen gevonden Ik heb zijn iptables-repeater.conf aangemaakt. en mijn jail.local aangepast met toevoeging van deze sectie:
[ssh-repeater]
enabled = true
filter = sshd
action = iptables-repeater[name=ssh]
sendmail-whois[name=SSH-repeater, dest=max, sender=fail2ban@monch.alpen, sendername="Fail2Ban"]
logpath = /var/log/fail2ban.log
maxretry = 21
findtime = 31536000
bantime = 31536000
Dit laatste heb ik nog niet goed kunnen testen. Want alle ip-adressen die kwamen aankloppen heb ik in de ban gedaan met fail2ban en ik heb ze nog niet teruggezien. Ik ben helemaal enthousiast. En die ervaring wil ik toch ook even delen! 
Mooi verhaal. Illustreert maar weer 's dat je met wat tijd nemen en lezen 't leven weer een stukje beter maakt. Ik ken dit probleem vooral van webservers. SSH-kloppers zijn eigenlijk 't vervelendst omdat ze de logs zo vervuilen. Bij mij kloppen ze ook op random welke poorten aan, 22 staat bij mij aan de buitenkant al dicht. Bij een voormalige klant hadden we dit wel aardig voor elkaar met een aantal gedownloade en aangepaste scripts die (bleek op een gegeven moment) zelfs heel Bangladesh blokkeerden via het automatisch ( meer dan zoveel uit het laatste octet, dan hele octet blokkeren ) toevoegen van iptables rules, kicken als er op een dag maar 10 zijn.