Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Apache

Installer Collabora Online avec Nextcloud

Rédigé par dada / 05 avril 2017 / 9 commentaires




Le soleil repointe le bout de son nez et je ne trouve plus le temps de sortir des billets. L'apéro passe avant tout mais malgré ça, j'ai quand même pas mal joué avec mon serveur.
D'abord, j'ai changé de crémerie, encore, pour laisser tomber mon C1 chez Scaleway pour une Kimsufi aux caractéristiques bien plus rigolotes : adieu l'ARM, coucou le Core i3. Ça m'a permis de mettre en place l'objet de ce billet : Collabora Online dans Nextcloud via Docker !

je présuppose que votre machine tourne sous Debian Jessie (what else ?) avec Nextcloud 11.0.2.

Installer Docker

Je suis passé par l'installation de Docker CE. Ça permet d'avoir une version plus récentes de la bête.

On commence par les dépendances qui vont bien :
apt-get install apt-transport-https ca-certificates curl software-properties-common 
On enchaîne sur la clé GPG du dépôt :
curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
On ajoute le dépôt dan le sources.list :
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" 
Pour finir, on installe notre nouveau jouet et c'est parti !
apt-get update && apt-get install docker-ce

Mise en place du conteneur de Collabora

On le télécharge :
docker pull collabora/code 
On le lance :
docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=votre\\.instance\\.com' --restart always --cap-add MKNOD collabora/code 
C'est pendant cette étape que je me suis le plus pris la tête... Ils disent de lancer docker avec pour paramètre un sous-domaine pour Collabora alors qu'il ne le faut pas, pas chez moi du moins. En fait, comme Collabora tourne sur le même serveur que mon instance, pas besoin de sous-domaine.

Configurer votre Vhost

Pour Nginx, ajoutez ces lignes dans votre vhost : (snippet ici).

    # static files     
    location ^~ /loleaflet {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;
    }       
    # WOPI discovery URL
        location ^~ /hosting/discovery {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;    
    }        
    # websockets, download, presentation and image upload
    location ^~ /lool {        
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;  
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
   }
Pour Apache2. c'est trop long alors cliquez sur snippet !

Et voilà pour le plus chiant !

Activer Collabora

Maintenant, pour terminer, allez donc activer l'application en la configurant avec le sous-domaine de votre instance : https://votre.instance.com. Pensez bien à cliquer sur "Appliquer" si vous ne voulez pas risquer de devenir chèvre...

Tous ces efforts vous permettront de cliquer paisiblement sur ces 3 nouvelles options :



Amusez-vous bien !

Partage de fichiers dans un réseau Windows

Rédigé par dada / 02 septembre 2016 / 11 commentaires


Réussir à partager des fichiers dans un environnement Windows semble simple, on installe Samba et c'est plié. J'ai pourtant rencontré trop de problèmes avec cette solution, j'ai lâché l'affaire et je me suis creusé le crâne. Ma situation est la suivante :
  • Un serveur destiné à partager des fichiers chez un hébergeur sous Debian
  • Un réseau familial sous Windows
  • Un besoin basique de sécurité
  • Un besoin de fiabilité
  • Une solution éprouvée
Je gère le serveur sous Debian sans problème. Je m'y connecte déjà en SSH et une paire de clés privée/publique avec un point de montage dans mon Nautilus. Y'a rien à ajouter, ça comble les besoins de sécurité.

Le réseau familial, j'ai absolument pas envie de me prendre la tête avec samba et sa configuration affreusement chiante. J'ai choisi un truc de feignant : Apache. Comme ça, pas de prise de tête, tout se fait via le navigateur. Pourquoi Apache ? Parce que je vais ajouter une pièce dans tout ce merdier : une Raspberry Pi première génération.
L’idée qui m'a traversé l'esprit est la suivante : faire un montage SSHFS sur une Raspberry Pi qui sera la seule à pouvoir se connecter au serveur et qui offrira son contenu aux membres du réseau via une IP privée. L’accès aux données distantes se fait via SSH et Apache s'occupe du reste dans l'unique boucle locale. Note importante : seul celui que a un accès au serveur peut partager des données. Tout se fait en sens unique.

Avec un schéma, ça donne ça :



Le dessin est mauvais, mais l’idée est là : un accès en sens unique pour les PC sous Windows via Firefox. Pour que tout ça tourne bien, il ne faut pas grand chose :
  • Une Raspberry Pi avec Raspbian, un utilisateur avec SSH et une IP fixe
  • Un serveur Apache tournant avec les droits group/user dudit utilisateur pour justement éviter les problèmes de droits (envvars).
  • Un point de montage SSHFS automatique dans le fstab si redémarrage intempestif il y a, et ça arrive toujours. Toujours
  • Un Vhost qui pointe vers ce point de montage
  • Un peu de temps
On se trouve donc avec une installation pas si simple que ça, quoique, mais qui aura le mérite de faire ce que je lui demande dans des conditions honorables. Après, en tant que DevOps (*rire*), je jongle avec ce que je sais faire de mieux : des serveurs, du SSH, de l'Apache et Debian.

Si vous avez des idées plus simples et aussi stables, je suis preneur. Je ne promets pas de les appliquer tout de suite, mais ça sera stocké quelque part.

Ah, et pour finir, je vais essayer de trouver un moyen de rendre l'affichage des fichiers partagés un peu moins laid  parce que le listing du contenant d'un répertoire est vraiment limite sous Apache.
Je me suis bien amusé à faire ça. J’espère que ça va vraiment tenir. Au final, je m’inquiète plus pour ma Raspberry Pi qui traîne en équilibre sur une Freebox que du bon fonctionnement de l'installation ;-)
 

Apache2 et mod_deflate : soulager votre serveur

Rédigé par dada / 21 octobre 2014 / 7 commentaires


Lorsqu'on s’héberge, on s'adapte aux capacités de son serveur et de sa ligne. J'ai commencé ce blog chez moi, sur une ligne Free pour particulier.

A l’époque, même s'il n’était pas monstrueux, mon serveur était un Intel Core 2 Duo plus que correct couplé à 2Go de Ram. Par contre, ma ligne ADSL me limitait lourdement : 128ko/s en upload, seulement. Et c’était le débit maximum si personne d'autre que moi ne traînait sur la machine.

En accord avec cette configuration, je me servais du mod_deflate pour qu'Apache compresse mes pages web avant de les envoyer sur la toile. Le processeur bossait dur et le débit montant respirait. Une page compressée prend moins de place dans les tuyaux, du coup, plus de gens peuvent y avoir accès.

En prenant un VPS chez Pulseheberg, j'ai complètement changé de configuration. Au revoir la limite de bande passante et bienvenue dans le monde des tout petits processeurs ARM. Le besoin de compresser les pages a disparu. Plus besoin du mod_deflate, mais je l'avais quand même ajouté par réflexe, habitude.

C'est en le faisant sauter, en le désactivant tout simplement que j'ai franchement gagné en réactivité. Le processeur ne bossant plus pour compresser mon contenu, la navigation sous ownCloud ou sous FreshRSS est devenue bien plus fluide.

Voici rapidement comment le faire sauter si vous ne savez pas s'il est activé :

Connectez-vous et tapez la commande suivante :

# a2dismod


Vous devriez voir ceci s'afficher :

# Your choices are: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi dir env mime negotiation php5 reqtimeout setenvif ssl status mod_deflate
Which module(s) do you want to disable (wildcards ok)?


Rentrez mod_deflate pour le désactiver et le tour est joué.

Edit : les commentaires me signalent une boulette. C'est "deflate" qu'il faut rechercher et non "mod_deflate" :)

Si vous êtes dans la même situation que moi, vous devriez sentir la différence ! :-)