Category Archives: web

OpenBSD 6.0 et installation de Ruby On Rails (rails pour les intimes)

Rails OpenBSDContrairement 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.

OpenBSD et Nextcloud

J’ai toujours mon serveur sous OpenBSD.Nextcloud-logo

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.

Mais Nextcloud est arrivé.

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.

Première étape

  • Téléchargement sur le site Nextcloud.
  • Téléchargement de l’application Calendar (Attention version correspondant à celle du serveur, actuellement version 9).
  • Téléchargement de l’application Contact (qui n’est plus installée par défaut).

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.

Seconde étape

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.nextcloud

Les applications Calendar et Contacts fonctionnent impeccable.

Open BSD & Ruby On rails

 

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.

Ruby et gems

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.).

Enfin Rails

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

Première application rails sous OpenBSD

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.

Mise à jour owncloud 7-> 8.1.x

Je me sers d’Owncloud pour mon “cloud personnel”.owncloud-logo

 

 

 

Mon Nuage à moi

En fait j’ai abandonné Google (calendar et drive) depuis maintenant des mois, pour un serveur personnel sous debian avec Owncloud installé dessus.

L’utilité principale est la disponibilité d’un serveur CalDav (de calendrier), mais la possibilité de fichiers, et de synchronisation loin de Dropbox me semblait utile (pas de quota, j’en suis à 65Go de synchronisé :-) ) initialement.
Finalement cela en devient aussi indispensable avec un usage certes personnel mais aussi professionnel. Sauvegarde du logiciel médical du cabinet sur le serveur professionnel, puis à distance via owncloud et sur les différents clients.

Me voici donc avec une application libre, a priori, d’une utilité qui en devient presque critique.

 

Et il  y a une mise à jour…

Les mises à jour Owncloud ont souvent été émaillées d’erreurs, de bug divers, avec impossibilité de retrouver les calendriers par exemple (version 6 ?) et autres minimes inconvénients gérables mais chronophages.

J’ai donc attendu quelques mois, que les bug remontent (c’est comme les nouveaux médicaments, ne jamais se jeter sur les nouveautés).

Et je me suis lancé.

Que j’ai effectué

La mise à jour se fait via le centre de mise à jour (version 7), et on croise les doigts.

Premier problème, un problème de droit sur un fichier. Réglé simplement.

Puis seconde erreur il manque un fichier ca-bundle.crt dans le dossier config… Renseignements pris sur le forum owncloud allemand, il faut récupérer le fichier d’archive comme pour une installation de novo. Puis ouvrir le zip et copier le fichier ca-bundle.crt du dossier owncloud/config vers votre dossier owncloud/config (idéalement /var/www/owncloud/config/).

On relance l’installation et hop cela fonctionne.

Quelques minutes après on redémarre sur un owncloud “tout” neuf.

Sauf que calendar est passé en application tierce optionnelle et doit être installée via le menu en haut à gauche, puis + applications.

Je clique sur activer dans le paragraphe dédié à l’application calendar et … Erreur. Le dossier existe déjà…

Je renomme le dossier apps/calendar en apps/calendar_vieux et relance l’activation. On repasse via le menu de mise à jour initial (petite frayeur pendant quelques secondes) et tadam cela fonctionne :-)

Idem pour les autres applications (contact, documents etc.).

Pour finalement réussir \o/

Owncloud fonctionne toujours assez bien, mais les mises à jours restent toujours une partie un peu difficile, non pas techniquement mais plutôt en temps et sueurs froides.

Rails sur Fedora 21

Après un abandon de la distribution linux Fedora devant la complexité de modification des partitions, j’y suis revenu en l’installant sur une machine virtuelle tournant sous windows 8.1.

Impératif professionnel aidant l’installation de Windows est une quasi obligation (même si j’explore la possibilité inverse, mais je ne veux pas tout casser pour le moment).

Me voici donc sous une machine virtuelle virtualbox sous Fedora 21. L’installation est simplissime et agréable, et tournant sur une machine confortable (i7/16 Go Ram) je l’installe sur un vieux disque 2.5″ 80Go d’un mac mini de 2007 (seul facteur limitant) avec 6 Go de RAM et accès à tous les cores du cpu.

Seulement pour certains développements j’ai besoin d’installer Ruby on Rails.
Sur les distributions debian que j’utilise communément j’utilise généralement RVM, puis installe un ruby, je télécharge les dernières rubygems et j’installe à la main rails en complétant les dépendances.
Cela roule mais c’est un peu fastidieux pour avoir une config récente.

Sur Fedora la méthode peut être identique, mais par défaut une simple ligne suffit
sudo yum install ruby ruby-devel rubygem-rails

Et me voilà avec une version de rails en 4.1.5 (pour rappel la dernière version est 4.2.1).

PS
Ah oui. Si vous utilisez sqlite comme base de données (comportement par défaut de rails) il faudra installer sqlite3-devel

sudo yum install sqlite-devel

PPS
Pour démarrer un serveur il vous faut un éxecutable javascript.
Installer nodejs dans le terminal
sudo yum install nodejs

Et dans le Gemfile rajouter
gem 'execjs'

et voilà …

Git, pense-bête pour débuter

Ça y est!

Après plusiuers mois de reagrds en coin, d’oeillades et de tentatives d’approche avortées je sors enfin avec git :-)

C’est finalement assez simple et puissant.

 

Le but est de synchroniser des versions d’applications ruby on rails entre un serveur central et plusieurs ordinateurs périphériques. Un peu bizarre vu que git est promu pour le côté décentralisé, mais dans mon cas cela risquait d’être un sacré bazaar :-)

Donc j’ai une application en développement sur un ordinateur
et je souhaite faire un dépot (repository en anglais) sur le serveur central et se synchroniser via ssh.

Serveur distant centralisé servant de dépot git principal

git init –bare depotapplicationtest.git

git début d’ordre donné à git

init création d’un dépot

–bare qui ne contiendra pas les fichiers en clair mais servira de référence

depotapplication.git le dossier qui servira de dépot. Finir par .git est une convention.

La configuration du serveur est finie. C’est pas long hein?

Git en local

Sur  l’ordinateur distant qui a une application Rails à synchroniser avec le dépot:

cd applicationtest/  je vais dans le dossier;

git init je déclare ce dossier comme étant un dépot git;

git add . (attention ne pas publier le point, j’additionne tous les dossiers, documents à la future synchronisation;

git commit -m “premier commit et autre commentaire” j’enregistre les changements.

Maintenant on a un dépot personnel git que l’on peut synchroniser avec d’autres ordinateurs périphériques, un autre dossier sur le même ordinateur, etc.

Mais le but est de le synchroniser avec le serveur centralisé.

git remote add origin ssh://utilisateurdistant@adresse_de_mon_serveur_centralise/chemin/du/dossier/dossierapplicationtest.git

 

remote add ajout d’un dépot distant;

origin nom du dépot;

ssh:// dépot avec lequel la connexion se fera en ssh avec l’adresse qui suit.

 

On a donc créé une relation entre le dépot sur l’ordinateur local et le dépot centralisé sur le serveur distant.

Maintenant on veut “remplir” le dépot central :

git push origin master

git push envoie les modifications des fichiers et dossiers;

origin nom du dépot

master branche du projet.

Dans mon cas vu que la clé ssh n’est pas encore définie la connexion nécessite l’entrée du mot de passe sur demande, et voilà !

J’ai maintenant un dépot centralisé sur lequel les modifications effectuées sur un ordinateur local seront mises à jour (après un git add . et un git commit -m”commentaire”).

Associer un autre dépot git.

Suposons que maintenant je veuille travailler sur le même projet à partir d’un autre ordinateur.

Sur celui-ci, git installé évidemment, je tape la commande

git clone ssh://utilisateurdistant@adresse_de_mon_serveur_centralise/chemin/du/dossier/dossierapplicationtest.git

qui va rapatrier en local les fichiers de l’application grâce à git clone suivi de l’adresse.

Une modification, un git add ., git commit -m “commentaire” et un git push origin master plus tard, le serveur est mis à jour.

Et de retour sur mon premier ordinateur périphérique. Je veux rapatrier les modifications effectuées. Je tape alors git pull origin master..

git pull ramenant les modifications du serveur vers le local.

C’est tout.

Pas mal non ?

 Mise à jour 20 avril 2013

A l’occasion d’un déplacement j’ai du modifier l’adresse locale de mon dépot git en adresse internet (la redirection des ports ssh étant automatique via la box).

Comment faire ? Tout simplement dans le dossier de mon projet en éditant via vim .git./config l’adresse du serveur. On sauvegarde et cela fonctionne à nouveau.

 

 

Rails 3 et la douleur du changement

Il existe tout un tas de connaissances qui méritent d’être acquises, de nouvelles technologies que l’on a envie de découvrir et d’explorer mais il est malheureusement impossible de tout connaître et se mettre à jour tous les jours est assez consommateur de temps pour n’être fait que si le besoin se fait ressentir.

Une technologie WEB de choix

Ceci est le critère principal de choix d’une technologie web.
Sa nouveauté, son aura car ici aussi la mode est bien présente, sa facilité d’appréhension, les éventuels gains de productivité attendus, et sa capacité à être suivie sur le long terme.

Ainsi Ruby on Rails est une de ces technologies qui semble remplir toutes ces qualités et que j’ai embrassé avec plaisir. Le temps passant, n’étant pas développeur à plein temps j’ai vu avec un soupçon de débordement évoluer ROR avec l’introduction de nouvelles technologies prometteuses à chaque mise à jour, l’obsolescence de nombreuses techniques de programmation, la mise au placard de technologies durement apprises et intégrées. Le tout avec un certain vertige et l’impression de débordement qui commence à me donner des sueurs froides.

Mais dont l’évolution déroute

ROR malgré une indéniable qualité technique, une productivité impressionnante et une facilité de déploiement accrue se tourne de plus en plus vers un modèle très professionnel de développement web avec des hyper-spécialistes et ses utilisateurs occasionnels. Or Ruby et par extension ROR sont des langages exigeant une certaine maîtrise afin d’en tirer le meilleur. En efficience du code, en qualité de programmation etc. Faire du PHP en ruby est au mieux une perte de temps.

Je suis devant donc un paradoxe d’une technologie web toujours aussi prometteuse mais dont le rythme d’évolution en devient angoissant pour qui essaye de se mettre un minimum à jour.

The Social Success

Honnêtement Facebook n’est pas ma tasse de thé, trop de vie privée, de voyeurisme et d’exhibitionnisme, des blogs en pire quoi…

Aussi “The Social Network” ne m’attirai pas trop, mais devant des conseils de relations et un petit .avi plus tard je me suis mis devant.

Et bien c’est une très bonne surprise. Le film démarre sur les chapeaux de roue, dans un anglais très rapide, difficile à suivre, mais on se prend au rythme et on se laisse porter par un film tonique bien documenté, avec de vrais dialogues d’informaticiens.

Le milieu de Harvard est rapidement décrit, et l’ambiance d’une startup qui rencontre le succès (chose rare) est enthousiasmant, Mark Zuckerberg est décrit comme un Nerd de base, son associé un bon petit gars gentil, un peu paumé et on a le droit à un très beau second rôle par Justin Timberlake dans le rôle du visionnaire un peu déjanté.

Bref Facebook est merdique mais ce film “The Social Network” est une perle.

On a pas tout perdu.

Un bon logiciel médical ?

Médecin et programmeur à mes heures perdues j’ai bien entendu réfléchi à ce que pourrait-être un bon logiciel médical de consultation, communication avec les autres progfessionnels, de suivi et de traitement.

“Développeur” Web en Ruby On Rails j’ai un projet sur le feu qui gère les consultations basiques, le suivi des paramètres, les examens demandés (sauf la biologie c’est en cours) les encaissements/dus, les notes, les choses à faire. Ce n’est pas grand chose mais cette avancée lente me permet de penser plus lentement, et j’en ai tiré plusieurs choses :

Un logiciel médical doit être ouvert, pour sa base de données, afin de l’interfacer avec d’autres logiciels et suivant un protocole multiplateforme de type soap, json,… J’en oublie sûrement beaucoup. Notre travail va être de plus en plus de la coordination avec d’autres acteurs de santé qui sont eux aussi de plus en plus informatisés.

Il faut éviter la double saisie qui est la voie certaine vers l’échec du partage d’information. L’idéal est donc d’avoir la possibilité que la base de donnée du médecin soit accessible en lecture (voire en écriture) et accessible via l’interface utilisée par les autres intervenants de santé.

Dans une maison de santé, qui ont la côte en ce moment, pourquoi ne pas imaginer :

Une base de données (idéalement Postgresql, MySQL a un avenir sombre, les autres solutions Open-source sont moins connues et les solutions propriétaires hors de prix) centrale sur laquelle on écrit

Des interfaces différenciées suivant les métiers, mais permettant la consultation/modification des données des autres professionnels. Imaginons que les infirmiers aient leur propre application, les médecins la leur, les psychologues aussi, et ainsi de suite, chacune avec une gestion des droits sur ce qu’ils peuvent consulter ou non.

Le tout sur un serveur hébergé par la maison médicale, et consultable à distance.

Le tout en application Web (exemple Ruby on Rails mais il y en a pas mal d’autres, je n’ai pas d’actions ;-) ) pour ne pas imposer un matériel et faire face aux différents moyens de consultaion, ordinateur, netbook, tablettes, smartphone etc.

Le bonheur non ?

La pérennité est assurée pour des dossiers médicaux qui doivent durer dans le temps (base de données en logiciel Libre, framework de développement idem), une maitrise des données qui sont hébergées en local, via une sous-traitance pour la maintence et le matériel, une grande souplesse d’utilisation et une absence de dépendnace à un éditeur si la solution est Open-Source (des coméptences de deéveloppeur Web on en trouve pas mal).

Voilà donc la voie idéale, mais la route est longue et la pente est rude. Je trouve illogique, choquant et stupide pour les financeurs de payer plusieurs fois pour un équipement informatique quand il eut été possible de payer une bonne fois pour toute pour produire un logiciel de base, adaptable à chacun et pouvant en plus participer à une économie locale de mainteneurs, développeurs etc.

C’est quand même pas gagné…