Mot-clé - openSUSE

Fil des billets

samedi 20 février 2016

La riposte de la communauté openSUSE face au projet KDE neon

Lors du dernier FOSDEM, Jonathan Riddell a annoncé un nouveau projet, KDE neon.

Il permet aux utilisateurs de tester les dernières versions des bibliothèques KDE Framework et Plasma 5 (le bureau) sur une base Ubuntu LTS [1], [2]. Les applications sont issues de la branche unstable du dépôt Git, et non pas d'archives comme on le trouve habituellement (il faut donc en tenir compte).

Le but est d'offrir aux utilisateurs des paquets en continu à partir de snapshots (considérés utilisables par les développeurs) du dépôt Git.

Le projet openSUSE a donc réagit est propose deux distributions contenant les tous derniers logiciels du bureau KDE Plasma.

Trois dépôts sont à activer si l'on souhaite utiliser les tous derniers logiciels du bureau KDE Plasma.

Il existe une initiative similaire pour le bureau GNOME Shell, GNOME:/Next.

Notes

[1] Ubuntu étant basé sur Debian, dont la réputation est d'être très stable.

[2] Jonathan Riddel a longtemps été un membre actif, pendant plus de 10 ans, auprès de la communauté Kubuntu, ceci expliquant l'utilisation d'une base Ubuntu pour ce nouveau projet.

[3] Cette distribution est basée sur SUSE Linux Enterprise (SLE)

[4] Également basée sur SLE, mais ayant le principe d'une rolling release.

lundi 19 janvier 2015

Installation de Dotclear sous openSUSE (bis)

Il y a quelques années, j'avais écrit un billet sur l'installation de Dotclear en local.

Nous allons donc revoir la procédure de A à Z, en changeant cette fois-ci de serveur Web, et de système de base de données.

Les prérequis sont :

  • Un serveur HTTP
  • Une base de données
  • PHP >= 5.2

Lire la suite...

lundi 22 décembre 2014

Upgrade sans filet !

logo openSUSE

Dans ce billet, je vais vous expliquer la procédure, que j'ai suivi pour mettre à jour (rapidement, et donc sans sauvegarde) mon système Linux (openSUSE).

Ceci a été décidé sur un coup de tête. Après un n-ième ras-le-bol suite à une mise à jour de sécurité, m'obligeant à démarrer uniquement en mode « dégradé » [1].

Note

[1] La mise à jour de sécurité n'a pourtant pas impacté la gestion de la carte graphique.

Lire la suite...

dimanche 29 janvier 2012

Exécuter une application WSGI avec systemd sous openSUSE

Ce billet est une « mise à jour » du précédent, concernant le déploiement de Mercurial, sous forme d'application WSGI.

Le fait de passer par le script /etc/init.d/after.local, pour lancer une telle application, ne m'a pas entièrement satisfait. C'est pourquoi j'ai décidé de me repencher sur ce point.

À la fin de l'article, j'évoqué, Gunicorn, comme serveur WSGI, en proposant même un exemple de fichier .service. Je me suis donc inspiré de celui-ci pour en créer un.

Le but c'est de pouvoir exécuter le script, hgweb.wsgi au démarrage.

Je vous propose donc, wsgi-hg.service. Il permet de lancer (ou d'arrêter) notre script WSGI. Il n'y a rien de particulier, à part la condition ConditionPathExistsGlob, qui me sert à tester si un fichier .wsgi (en réalité hgweb.wsgi) est présent sur le serveur, si c'est le cas, le service pourra être lancé.

Il faut bien sur, avoir correctement configuré son serveur Web. Par exemple pour Nginx :

[...]

    # Subdomain settings
    #
    # Mercurial
    #
    server {
	listen 80;
	server_name hg.errements.net;

	access_log /var/log/nginx/access-hg.log;

	location / {
		root /srv/www/htdocs/vhosts/hg;
		autoindex	off;

		proxy_path	http://127.0.0.1:8500;
		proxy_set_header	Host	$host;
	}
    }

[...]

Mais on peut aller encore plus loin, actuellement dans notre script wsgi, le socket réseau (le port, et l'adresse IP) sont codés en « dur ». On pourrait les passer en paramètre. Il faut pour cela utiliser le module argparse.

olivier@bornem:~ $ python hgweb-opts.wsgi -h                                 
usage: hgweb-opts.wsgi [-h] host port

positional arguments:
  host        Add IP address
  port        Add port number

optional arguments:
  -h, --help  show this help message and exit
olivier@bornem:~ $ 

On peut voir que deux paramètres sont obligatoires, l'ordre à une importance.

  • host, par exemple 127.0.0.1
  • port, par exemple 8500
olivier@bornem:~ $ python hgweb-opts.wsgi 127.0.0.1 8500                     
serving on http://127.0.0.1:8500

On peut maintenant adapter le fichier wsgi-hg.service, pour pouvoir passer ces paramètres à la ligne ExecStart.

Voici la ligne à copier.

[...]
ExecStart=/usr/bin/python2.7 /srv/www/htdocs/vhosts/hg/hgweb-opts.wsgi 127.0.0.1 8500
[...]

Pour lancer le service, on place ce fichier dans /etc/systemd/system/default.target.wants/ (ou /lib/systemd/system/).

root@bornem:~ # systemctl start wsgi-hg.service
root@bornem:~ # systemctl status wsgi-hg.service
wsgi-hg.service - Starts WSGI script (mercurial)
	  Loaded: loaded (/lib/systemd/system/wsgi-hg.service; disabled)
	  Active: active (running) since Sun, 29 Jan 2012 21:26:45 +0100; 38s ago
	 Process: 17745 ExecStartPre=/bin/echo Starting WSGI script for mercurial  (code=exited, status=0/SUCCESS)
	Main PID: 17747 (python2.7)
	  CGroup: name=systemd:/system/wsgi-hg.service
		  └ 17747 /usr/bin/python2.7 /srv/www/htdocs/vhosts/hg/hgweb...
root@bornem:~ # 

lundi 23 janvier 2012

Déployer Mercurial (hg) « derrière » un serveur Web (Nginx) sous openSUSE

Logos

Dans un précédent billet, j'avais montré comment l'on pouvait exécuter une application Web écrite dans le langage Python sans faire intervenir de serveurs Web.

Aujourd'hui, nous allons voir le cas, où un serveur (en l'occurence Nginx) est déjà en place.

En fait, le but inavoué de cet article est de comprendre le système d'init, systemd utilisé par openSUSE en autre.

Lire la suite...

lundi 21 novembre 2011

Upgrade openSUSE

logo openSUSE

La dernière version de openSUSE est sortie le 16 novembre. C'est la distribution Linux que j'utilise actuellement sur mon ordinateur principal. J'ai profité de ce week-end pour faire la mise à jour.

Je suis reparti complètement de zéro car :

  • le partitionnement ne me convenait plus
  • j'étais sous GNOME2 (2.32)

Désormais, j'utilise KDE4, et je vais pouvoir me consacrer un peu plus à la création de paquets RPM.

Dans ce billet, je vais présenter, les principales modifications que j'ai apporté, afin d'avoir un système qui me convienne.

Lire la suite...

samedi 13 août 2011

Installation de Dotclear en local, sous openSUSE

logo openSUSE logo de Dotclear

Pour célébrer les huit ans de Dotclear, j'en profite donc pour présenter une méthode pour installer ce fabuleux système de blog sur son ordinateur en « local ».

Pré-requis

  • Un serveur Web, Lighttpd
  • PHP5 avec le module FastCGI (indispensable) ou PHP-FPM
  • SQLite [1] (installez bien le module PHP pour cette base de données)

Tous ces composants ont été installés via zypper (vous pouvez très bien passer par Yast2).

Régler le daemon

Comme il s'agit de mon ordinateur de bureau, je n'ai pas l'intention de le lancer à chaque démarrage, il sera utilisé ponctuellement.

# chkconfig --list | grep lighttpd
lighttpd                  0:off  1:off  2:off  3:on   4:off  5:on   6:off

On constate qu'il est activé lorsque le système est en mode multi-users (numéros 3 et 5).

Nous allons donc désactiver ce service

# chkconfig --del lighttpd
# chkconfig --list | grep lighttpd
lighttpd                  0:off  1:off  2:off  3:off   4:off  5:off   6:off

Désormais, on le lancera de cette manière :

# /etc/init.d/lighttpd start

Configuration du serveur

Dans cette partie, nous allons modifier (légèrement) le comportement par défaut de Lighttpd.

Le fichier principale s'appelle lighttpd.conf, il est situé dans /etc/lighttpd.

J'ai modifié la valeur des variables server_root , server.use-ipv6 et server.bind.

[...]
var.server_root = "/usr/www"

[...]
##
## Use IPv6?
##
server.use-ipv6 = "disable"

##
## bind to a specific IP
##
server.bind = "127.0.0.1"

[...]

Il reste à créer les répertoires /usr/www/htdocs :

# mkdir -p /usr/www/htdocs
# cd /usr/www ; chown -R lighttpd:lighttpd .

Ensuite, on va autoriser le listing des répertoires situés dans server_root, il faut modifier le fichier /etc/lighttpd/conf.d/dirlisting.conf

[...]
##
## Enabled Directory listing
##
dir-listing.activate      = "enable"
 
##
## Hide dot files from the listing?
## By default they are listed.
##
dir-listing.hide-dotfiles = "enable"

Pour une question de facilité, on va activer le module userdir, il faut décommenter la ligne correspondante dans le fichier /etc/lighttpd/modules.conf :

[...]

##
## mod_userdir
##
include "conf.d/userdir.conf"

[...]

Vous pouvez activer la variable userdir.exclude-user dans le fichier /etc/lighttpd/conf.d/userdir.conf

[...]
userdir.exclude-user = ( "root" )

[...]

Il nous reste plus qu'à créer le dossier public_html/ pour chaque utilisateur.

% mkdir ~/public_html

Vous pouvez maintenant tester le serveur.

PHP

Nous allons utilisé PHP avec le module FastCGI.

On va rechercher le nom exacte de ce binaire :

% ls /usr/bin/php* | grep cgi
/usr/bin/php-cgi   **
/usr/bin/php-cgi5

** : Il s'agit d'un lien symbolique vers /etc/alternatives/php-cgi, donc on l'oublie (vérifiez tout de même avec ls -l /usr/bin/php-cgi*).

On va rajouter ce module au démarrage du serveur, grâce au fichier /etc/lighttpd/modules.conf

[...]
##
## FastCGI (mod_fastcgi)
##
include "conf.d/fastcgi.conf"

[...]

Il ne nous reste plus qu'à rajouter une directive dans le fichier /etc/lighttpd/conf.d/fastcgi.conf :

[...]

fastcgi.server = ( ".php" =>
     ( "localhost" =>
         (
         "socket" => socket_dir + "/php-fastcgi-0.socket",
         "bin-path" => "/usr/bin/php-cgi5",
         "max-procs" => 1,
         "check-local" => "disable"
         )
     )
)

[...]

On peut relancer notre serveur.

Ici on utilise un socket UNIX, mais on peut très bien utiliser un socket utilisant la pile TCP/IP.

Installation de Dotclear

1. Téléchargez et installez le dans le dossier public_html/.

2. Il faut rendre accessible en écriture le répertoire cache/ :

% chmod a+w dotclear/cache

3. On va créer le « fichier » de la base de données (uniquement pour SQLite)

% touch db/database.db ; chmod a+w db/database.db
% chmod a+w db/

Vous pouvez donner un autre nom, ceci est un exemple.

4. On copie le fichier inc/config.php.in en inc/config.php et on l'édite. Les variables à modifier sont :

  • DC_DBDRIVER
  • DC_DBNAME (mettre le chemin complet depuis la racine du fichier du §3)
  • DC_MASTER_KEY

On termine l'installation en faisant pointer notre navigateur vers http://127.0.0.1/dotclear/admin/install/

Finaliser la configuration du serveur

On va empêcher le listing de la base de données, dans le fichier /etc/lighttpd/conf.d/dirlisting.conf on va rajouter une expression régulière à la variable dir-listing.exclude :

[...]

##
## list of regular expressions. Files that match any of the specified
## regular expressions will be excluded from directory listings.
##
dir-listing.exclude       = ( "~$", ".+\.db$" )

[...]

On va également interdir l'accès (depuis un navigateur) aux répertoires dotclear/db/ et dotclear/admin/install/. Pour cela il faut activer le module, mod_access (via le fichier /etc/lighttpd/modules.conf).

Dans le fichier /etc/lighttpd/lighttpd.conf on rajoute ces lignes :

[...]

##
## deny access to dotclear/db/ and dotclear/admin/install/
$HTTP["url"] =~ "(/db/|/install/)" {
     url.access-deny = ( "" )
}

On va empêcher le listing du répertoire public/, où sont stockés les médias tels que les images, les vidéos, etc. Dans le fichier /etc/lighttpd/conf.d/dirlisting.conf on rajoute ces lignes :

[...]

##
## Disable listin into public/ directory
$HTTP["url"] =~ "/public/" {
     dir-listing.activate = "disable"
}

[...]

Maintenant vous pouvez passer des heures à configurer votre blog.

Notes

[1] Je n'avais pas envie de passer du temps à configurer MySQL ou PostgreSQL.