Mise à jour il y a 14 jours pour la nouvelle version d’OpenBSD qui est déjà sortie il y a un bout de temps.
Contrairement à la procédure de mise à jour pour 6.0, après téléchargement du noyau bsd.rd et redémarrage en suivant les instructions déjà données pour la version 6.0 la mise à jour se passe sans problèmes.
Et rails fonctionne toujours aussi bien.
Viber sapucpaslibretm mais bon parfois il faut bien être social et avant que je ne monte mon serveur diaspora (dans la liste des choses à faire) je me suis résolu à l’utiliser.
Sur android cela fonctionne bien, mais en plus il y a un client linux \o/
Téléchargement du paquet .deb sur une debian au travail virtualisée, installation sans messages d’erreur, mais au lancement, rien.
Nichts.
Nada.
La commande viber dans le terminal ne donne rien (viber n’est pas installée…).
et puis en farfouillant un peu, en lançant /opt/viber/Viber on obtient enfin un mesage d’erreur exploitable
QSqlDatabasePrivate::removeDatabase: connection 'ConfigureDBConnection' is still in use, all queries will cease to work.
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".
La partie “could not find Qt platform plugin “xcb” ” permet de retrouver le net qu’il faut installer
# apt-get install "^libxcb.*" libx11-xcb-dev libglu1-mesa-dev libxrender-dev
Redémarrage de l’application et c’est parti \o/
Bon le truc nul est que les conversations précédentes ne viennent pas sur le client …
Contrairement au dernier épisode sous openbsd 5.9 l’installation de ruby on rails sur Openbsd 6 est un peu plus compliquée (j’aime les euphémismes).
Il vous faut :
OpenBSD tout neuf a priori, ou non.
Il faut d’abord installer votre éditeur de texte préféré (j’ai dit vim ? ).
Puis installation de ruby
# pkg_add ruby
On vous propose différentes versions j’ai choisi à ce jour le 2.3 – choix 4.
L’installation de ruby est un peu étrange au sens ou elle installe des exécutifs finis par le numéro de version. Ainsi ruby 2.3 devient ruby23 dans /usr/local/bin, idem pour les autres exécutables (bundle, bundler, rake etc…). Je pressens quelques raisons mais bon…
À la fin de l’installation on vous recommande de faire des liens symboliques pour lier la commande ruby avec l’exécutable ruby23 par exemple (mais les autres aussi).
Les prochaines commandes considéreront que les liens n’ont pas été créés.
Voici maintenant l’installation de rails, il est visiblement admis qu’il est préférable de les mettre dans un dossier de l’utilisateur (cela sera .gem). Il faut intégrer le nouveau chemin des gem installées dans le path
fichier .profile PATH=$PATH:~/.gem/ruby/2.3/bin:
ou bien à la suite des autres chemins
~/.gem/ruby/2.3/bin:
On quitte le shell et on revient et on installe rails.
$ gem23 install rails --user-install
Parfois la gem nokogiri ne s’installe pas (cela a marché deux fois et raté deux fois…).
Il faut donc installer
# pkg_add libxml libxslt
et
$ gem23 install --user-install nokogiri -- --use-system-libraries --with-xml2-config=/usr/local/bin/xml2-config --with-xslt-config=/usr/local/bin/xslt-config
Dans le dossier utilisateurs par exemple je fais la commande
$ rails new appbidon
Tout se passe bien…
Jusqu’au bundle install qui rate sur rake. Pas de panique. On va dans le dossier de l’application, et on lance
$ bundle23 install --path ~/.gem
Tout se passe bien.
Je passe dans le dossier de l’app créée puis lance le serveur
$ rails23 s
À ce stade cela va échouer, mais c’est un “problème” connu des utilisateurs de rails.
Il faut installer un moteur javascript et curieusement therubyracer qui nécessite la libv8 ne s’installe pas bien (problème avec python ??)
On va donc installer nodejs.
# pkg_add node
Insérer la gem node dans le Gemfile (sous la ligne therubyracer)
fichier appbidon/Gemfile gem 'node'
Faire un
bundle23 install --path ~/.gem (dans le dossier de l'application). rails23 s
Et alleluiah le serveur démarre sur localhost:3000
Seul problème actuel en local cela va (lynx sur la machine hôte qui pointe sur localhost:3000) mais de l’extérieur cela n’est pas atteignable…
Il faut faire un bind du serveur sur l’adresse 0.0.0.0
La commande devient
rails23 s -b 0.0.0.0
On pointe un navigateur sur l’IP port 3000 et cela fonctionne.
Bon maintenant reste plus qu’à coder :-)
PS.
Merci aux aides sur internet, la liste railsfrance et le questions/réponses sur OpenBSD animé par thuban.
Je vais faire un résumé, cela sera plus simple. Voire une version en anglais et italien…
PPS.
Les commandes:
# ln -sf /usr/local/bin/XXX23 /usr/local/binXXX $ ln -sf ~/.gem/ruby/2.3/bin/XXX23 ~/.gem/ruby/2.3/bin/XXX
sont tes amies pour simplifier la vie. Et il y a encore des trucs que je n’ai pas pigé sur le pourquoi du comment.
Il est temps de mettre à jour.
La mise à jour peut se faire via un média d’installation, sur une clef usb ou un CD, mais sur ma machine le démarrage sur USB est un peu capricieux.
Je cherche donc une autre méthode.
Renseignements pris, et avec le support du récent article de Thuban sur yeuxdelibad il y a la méthode via le dépot dans le dossier racine du noyau bsd.rd, et au redémarrage, lors de l’invite
boot> boot bsd.rd
puis (U)pdate.
Mais là c’est la connexion aux serveurs qui est capricieuse, avec une réponse : les sets xxx ne se pas retrouvés sur le serveur etc. Malgré l’essai de 4 mirroirs différents …
Me voilà dans la mouise.
Mais au démarrage sur le noyau j’ai vu passer l’option disk. Illumination, ma clef usb avec la version Openbsd 6 est encore branchée !
Je tape donc disk, je répond que le disque n’est pas monté et on me propose automatiquement le disque sd0. La partition est la a (la plus grosse –size matters :-) – ).
Je retrouve alors l’installation classique, les sets sont pré-selectionnés, et roule ma poule tout s’installe sans problèmes.
Reboot
Openbsd version 6.0.
Le reste est du “classique”.
Connexion en root, pkg_add -u et voilà.
Me voilà à jour.
Au fur et à mesure que je suis certains blogs et articles sur l’autohébergement je me suis dit que j’allais parler de mon expérience sur le sujet.
Je ne suis pas développeur professionnel, plus un script kiddie et autodidacte qu’autre chose, mais la notion d’indépendance et de maitrise des données est importante pour moi, et le fun de le faire soi-même, inégalable…
Donc voilà 2012 à l’occasion d’une promo (100 € dez réduction sur les microserveurs hp à 325 €) je m’équipe d’un serveur, de quelquies disques et j’installe une debian.
L’installation de Debian se passe sans problèmes.
D’abord la sécurité avec un fail2ban, un mot de passe fort (pas de clef, pas asez calé à l’époque) associé à un nom d’utilisateur un peu compliqué, un permitrootlogin no dans le sshd config.
Un blocage des ports non utilisés.
Je comptais utiliser Owncloud alors débutant, piwigo, sans compter un peu d’appli rails avec des repos git, un accès ssh et ftp distant.
Les problèmes habituels de l’autohébergement sont bien sur présents.
Le bruit du serveur dans une maison est moins génant, les coupures d’électricité sont maintenant exceptionnelles, l’upload est un peu embêtant mais passée la première synchronisation, au vu du volume faible de données, cela reste acceptable pour une utlisation quotidienne.
La sécurité est toujours par contre un problème avec pas mal de tentatives de connexions, d’où l’utilité de bloquer le compte root, et d’activer fail2ban, sans compter les tentatives de connexion sur le serveur port 80 avec des sous domaines au nom de mysql, phpmyadmin, sqlite, pma etc.
Donc premier adage mettre des noms exotiques. “Rainman” pour un gestionnaire de bases de données ? (comprenne qui pourra :-) ).
Mais on n’est pas à m’abri d’une faille zeroday ou bien une faille sur un CMS, d’où l’utilité de n’utiliser que peu de services mais qui fait pas mal de choses. J’avais considéré le principe GNU une application pour un but (calendrier, fichiers, etc.) mais en fait cela multiplie les portes d’entrée.
Finalement au bout de ces 4 années d’utilisation j’en suis satisfait, le serveur hp tient la route avec le peu de charge que je lui fait subir. Je sauvegarde les données avec un disque de sauvegarde de 4To en plus, celle des calendriers se fait via un script sur un autre serveur à distance (un autre lieu) et un nettoyage de temps en temps.
La version de Debian reste assez ancienne (6) et à l’occasion d’une mise à jour je compte passer en Openbsd suite à la série d’articles de Thuban et un début de mon expérience personnelle… Mais c’est une autre histoire.
J’ai toujours mon serveur sous OpenBSD.
J’ai toujours un serveur perso sous debian qui gère une instance Owncloud depuis des années (article bientôt promis)
La prochaine étape est donc un serveur OpenBSD avec une application Owncloud.
Nextcloud c’est un fork, c’est à dire une reprise du logiciel Owncloud qui est un logiciel libre, par les fondateurs qui ont quitté le navire officiel pour voler de leurs propres ailes (pourquoi? un désaccord avec les financiers ne m’étonnerait pas).
Fidèle à cette idée de logiciel libre j’ai bien sûr envie de passer à Nextcloud.
Sur OpenBSD il y a donc le serveur par défaut, httpd, qui me semble très bien pour mon utilisation basique.
La base de données Sqlite suffira. Le nombre de fichiers sera peu important.
Par contre j’ai besoin de l’application calendriers et de celle des contacts.
Puis décompression de Nextcloud dans le dossier /var/www/htdocs du serveur, les applications Calendar et Contact seront décompressées dans le sous-dossier apps.
On considère que l’activation du PHP a été réalisée sur votre serveur, que le fichier httpd.conf est bon, que Sqlite est installée. On point donc un navigateur sur l’adresse réseau du serveur genre :
http://192.168.1.42/nextcloud
Etrangement il ne me propose pas la base de donnée MySql (mariaDB chez moi) malgré une configuration qui me semble bonne. M’en fiche j’utilise sqlite…
Et le reste de la configuration est la même qu’Owncloud avec modification (en root ou en doas) des droits du dossier data :
# chown www:www data
La modification du dossier config aussi et c’est bon.
L’application est donc la même qu’Owncloud avec juste un changement des couleurs et certaines options non encore explorées qui sont présentes.
Les applications Calendar et Contacts fonctionnent impeccable.
Parfois vous avez du matériel qui tombe en panne chez vous. Mais je suis assez sensible à la réparabilité des choses, je tends à conserver un tas de trucs cassés, pour le jour où…
Aussi le jour ou ma lampe Foscarini Blob S, d’un coût initial loin d’être négligeable, est tombée en panne j’ai dégainé mon kit iFixit et commencé à démonter le machin.
Bien entendu aucun manuel de réparation ou de dépannage sur le site du fabricant, même si on trouve une notice de montage sur un mur) et mes emails sont restés sans réponse (même en italien :-) ).
Je m’attaque donc au démontage, pas trop effrayé vue la simplicité a priori.
Premières vis des 6 pans, l’intérieur consiste en un petit boitier Osram, relié à la douille 2G11 et le tube néon correspondant. Et trois autres vis cruciforme pour démonter le tout.
Après un test du tube (même format d’ampoule qu’au travail, cela aide) et des cables, c’est finalement le ballast(le boitier Osram) qui s’avère être le point faible.
La commande de ce petit boitier à moins de 10 euros est rapide.
Une fois reçu il suffit d’ôter les fils en gardant en mémoire la connexion des fils entrants et sortants. Je remonte le tout et voilà.
Le test est positif.
Je remonte et j’ai une lampe ‘presque’ neuve pour dix euros.
Je ne remercie pas Foscarini, qui au prix de ses luminaires ne favorise pas la maintenance et la réparation…
Attention nouvelle version pour OpenBSD 6 il faut cliquer sur la phrase :-)
Suite à l’installation, la configuration sommaire de mon serveur sous OpenBSD, je rentre dans le vif du sujet avec l’installation du framework (cadriciel ? ) ruby on rails.
L’installation commence par celle de la bonne version de ruby et ses rubygems associées. Sur les distributions habituelle on installe un gestionnaire de version de ruby et gems associées, rvm ou rbenv.
Ici l’installation se fait via
# pkg_add ruby
Le choix vous est donné entre les différentes versions de ruby. J’ai installé la dernière version (2.3) et à la fin de l’installation il faut créer des liens symboliques dans /usr/local/bin/ dirigeant vers les versions actuelles des éxecutables ruby (ici ruby23 mais aussi les autres éxecutables tels puma, rake, bundle etc.).
La commande suivante:
# gem install rails
installe donc notre famework (cadriciel ?) préféré sans encombre.
Sans encombre ? presque, car la commande rails ne donne rien, ou tout du moins
$ rails -v $ rails: command not found
Le problème, comme pour l’installation de ruby est de créer un lien symbolique dans
/usr/local/bin/
de rails vers rails23 (23 correspondant à la version 2.3 de ruby qui est installée). Soit la commande :
# ln -s /usr/local/bin/rails23 /usr/local/bin/rails
La première application sera créée par
$ rails new essaidapplicationbidon
Le bundle install fonctionne sans problèmes.
Après la suite (partage réseau, sauvegarde automatisée …)
PS. À noter un nouvel article sur openbsd par Thuran pour mettre à jour votre système.
Juste un pense-bête.
Ksh c’est bien mais j’ai plus mon habitude avec bash.
# pkg_add bash $ chsh -s bash
On quitte la session, on redémarre et voilà :-)
Toujours sur mon openbsd, je l’intègre dans un réseau avec une ip fixe.
Mais comment faire ?
Finalement c’est assez simple. Une fois installé votre éditeur de texte favori via un
$ pkg_add vim
et il vous propose plusieurs versions (comme je suis en connexion à distance j’ai pris vim sans x11).
Puis je passe en root et modifie mon fichier pour l’interface qui est simplissime.
$ su root
# vim /etc/hostname.re0
Comment re0 ?
La commande ifconfig donne la liste de toutes les interfaces et celle qui contient votre adresse IP est l’interface utilisée par l’ordinateur.
$ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 re0: flags=18843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,MPSAFE> mtu 1500 lladdr 00:1f:d0:a1:b6:99 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.92.224 netmask 0xffffff00 broadcast 192.168.92.255 enc0: flags=0<> priority: 0 groups: enc status: active pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144 priority: 0 groups: pflog
Le fichier est simple, tellement que je me suis demandé si je ne m’étais pas trompé :
dhcp
J’efface donc ce simple terme et le remplace par
inet 192.168.92.224 255.255.255.0 NONE # votre adresse IP fixe suivi du masque de sous-réseau
!route add default 192.168.92.1 #l'adresse du routeur
Enfin un truc de barbu :-)
On redémarre, non pas le serveur mais juste l’interface réseau via
# sh /etc/netstart
et ifconfig confirme le changement d’adresse IP, et ma session ssh n’a même pas quitté. Si c’est pas beau \o/ .
(presque il vaut mieux redémarrer quand même…).