Relia Fanless Industrial PC : fanless oui, industriel pas trop.

Depuis un moment, pour des raisons de silence et surtout d’encombrement, je voulais remplacer mon routeur (une tour ATX avec ventilation relativement silencieuse) par un boitier compact sans ventilateur. Les conditions à remplir étaient les suivantes :

  • ventilation passive,
  • puissance CPU d’actualité, et 64bits
  • 2 ports ethernet, grand minimum,
  • WIFI,
  • port série,
  • 2 emplacements pour disque dur, grand minimum,
  • ne pas coûter un bras.

En cherchant des petits PC fanless “industriels” je suis tombé sur Aleutia, qui propose le modèle Relia. Celui-ci rempli approximativement le cahier des charges. Surtout, les gens chez Aleutia ont bien assuré l’avant-vente, répondant à mes nombreuses questions avec rapidité et précision. Pour la somme pas vraiment négligeable de 848,32 euros j’ai :

  • un mini PC sans ventilateur,
  • Core i3 2.8 GHz,
  • 8 Go de RAM,
  • carte Wifi/Bluetooth avec deux antennes de 30cm,
  • (seulement) 2 ports ethernet,
  • SSD de 64 Go mini-PCIe,
  • 2 emplacements pour disques durs de 2,5″.

Aleutia Reliacrédit photo : Aleutia

Comme l’engin n’a que 2 ports ethernet, il m’a fallu ajouter un mini switch ethernet silencieux (Netgear GS105E) pour 25 euros de plus. J’ai aussi monté dans le boitier 2 disques HGST Travelstar 7K1000 en SATA III, 1To chaque.
Montant total : 1032 euros et 19 cents.

Sur le plan physique, je suis satisfait de mon achat. L’alimentation externe est petite et discrète et le PC est compact, très robuste, d’un beau noir mat. Il est incontestablement d’aspect industriel, à tel point que je ne laisserai pas des gamins jouer avec : en le manipulant on peut se faire mal sur les angles des radiateurs latéraux. Il est livré dans la boite d’origine du fabricant Streacom.

Sur le plan du silence par contre, on repassera. La machine émet une sorte de couinement aigu, d’intensité variable et inversement proportionnelle à la charge CPU. Ce bruit d’origine électronique est désagréable, car il porte loin et que j’y suis sensible. Moralité, pas besoin de ventilateur pour polluer l’ambiance. Par dessus, j’ai rajouté les deux disques qui font, même inactifs, un léger bruit de ventilateur.

À l’intérieur ça se corse. La carte mère est un simple modèle de bureau, la Intel DQ77KB. Et ça, ce n’est pas une bonne nouvelle (même si je le savais avant d’acheter). Pour faire simple, et court, je découvre les joies des “interrupt storms”, des chipsets qui font tout sauf le café, et qui donc ne font pas forcément bien le travail. Je me retrouve aussi face à un BIOS pas très robuste et manquant de souplesse.
Il n’y a que sur une carte mère grand public que le système d’exploitation peut perdre les pédales quand on branche un écran. Là où une carte de serveur aurait une électronique bien mieux cloisonnée, et un simple port VGA bien robuste, on a ici sans doute trop de gadgets sur la même ligne d’IRQ. Au hasard : l’IRQ 16 c’est 6 ports USB3 et USB2, un port Displayport et un port HDMI.
Alors bien sûr, il y a vraisemblablement un bug du côté de FreeBSD, mais avec une carte mère Tyan ou Supermicro, je n’aurais eu aucun problème. Résultat, le port HDMI est totalement inutilisable, sauf en cas d’urgence. C’est une machine headless, donc j’en fais le deuil, mais c’est pénible.
Autre souci, et non des moindres : la carte Wifi vendue avec le Relia est une Intel Centrino Advanced-N 6230. Elle fonctionne, mais elle ne permet pas la création d’un point d’accès (mode hostap). C’est uniquement dans ce but que j’ai besoin d’une carte Wifi. Je dois donc trouver une alternative compatible hostap, qui rentre dans un slot half-mini PCIe. Je cherche encore…
Et pour finir, les câbles SATA fournis par Aleutia ont des prises droites, qui s’avèrent problématiques pour brancher les disques sur les ports SATA III. Heureusement, j’avais des câbles coudés en réserve.

Comme évoqué plus haut, Aleutia a bien assuré la phase d’avant-vente. Par contre, l’après-vente est très décevante. J’ai contacté une fois le support technique : pas de réponse. J’ai donné des info à l’ingénieur avant vente au sujet de la compatibilité de la carte Wifi avec le mode hostap : pas de réponse. En gros, j’ai le sentiment qu’une fois qu’on a payé, on n’est plus trop intéressant pour eux.

Un peu de positif tout de même : j’ai pu installer assez facilement FreeBSD 9.1 sur le SSD, intégralement sur ZFS (même le swap). Les deux disques durs, dont on me reprochera le fait qu’ils ne sont pas très fiables, servent à stocker mes sauvegardes d’autres machines. J’ai donc volontairement choisi un bon rapport volume/prix, la fiabilité est un peu secondaire. Ils sont aussi formatés en ZFS avec un alignement de 4K.
Je constate néanmoins des soucis de performance. Si j’envoie un gros volume de données entre un des disques et le SSD, la charge CPU monte facilement à 15-20, et je peux perdre la main jusqu’à la fin du transfert. La compression gzip que j’utilise sur de nombreux volumes est sans doute en cause.

Le bilan est plus que mitigé. Le Relia remplace un PC bi xeon LV dual core (Sossaman 32 bits), carte mère Tyan, avec 3 ports ethernet et une carte Wifi en access point. Certes il prenait de la place, et était ventilé, mais il avait aussi un port série pour le branchement de ma sonde de température et mon lecteur de iButton. Finalement, je gagne ZFS sur du 64bits, et je multiplie ma RAM par 8, je supprime une tour du salon, mais pour le reste je ne me sens pas gagnant !

Track mpm-itk problems with truss

Some background

I’ve some security needs on a shared hosting web server at work and I’ve ended up installing Apache-mpm-itk in place of my old vanilla Apache server. MPM-ITK is a piece of software (a set of patches in fact) you apply onto Apache source code to change it’s natural behavior.
Out of the box, Apache spawns a handful of children httpd belonging to user www:www or whatever your config is using. Only the parent httpd belongs to root.
Hence, every single httpd must be able to read (and sometimes write) web site files. Now imagine you exploit a vulnerability into a php CMS, successfully injecting a php shell. Now through this php shell, you are www on the server, you can do everything www can, and it’s bad, because you can even hack the other web sites of the server that have no known vulnerability.
With MPM-ITK, Apache spawns a handfull of master processes running as root, and accordingly to your config files, each httpd serving a particular virtual host or directory will switch from root to a user:group of your choice. So, one httpd process currently serving files from web site “foo” cannot access file from web site “bar”: an attacker exploiting a vulnerability of one particular web site won’t be able to hack every other web site on the server.

More background

That’s a world you could dream of. In real world, that’s not so simple. In particular, you’ll start having troubles as soon as you make use of fancy features, especially when you fail to provide a dedicated virtual host per user.
On the shared server we host about 35 vhosts for 250 web sites, and we can’t afford to provide every user with his dedicated vhost. The result is a given virtual host with a default value for the fallback user:group (say www:www), and each web site configured via Directory to use a different dedicated user.

When a client GET a resource (web page, img, css…) it generally keeps the connection opened with the httpd process. And it can happen that a resource linked from a web page sits into another directory, belonging to another user. The httpd process has already switched from root to user1 to serve the web page, it can’t switch to user2 to serve the linked image from user2′s directory. So Apache drops the connection, spawns a new httpd process, switches to user2, and serves the requested resource.
When it happens, you can read things like this into your Apache error log:

[warn] (itkmpm: pid=38130 uid=1002, gid=80) itk_post_perdir_config(): 
initgroups(www, 80): Operation not permitted
[warn] Couldn't set uid/gid/priority, closing connection.

That’s perfectly “legal” behavior, don’t be afraid, unless you read hundreds of new warning every minute.
If you host various web sites, belonging to various users, into the same vhost, you’re likely to see many of these triggered by the /favicon.ico request.

Where it just breaks

When things are getting ugly is the moment a user tries to use one of your available mod_auth* variant to add some user authentication (think .htaccess). Remember, I host many web sites in a single vhost, each one into its own directory with its own user:group.

Suddenly every single visitor trying to access the protected directory or subdirectory is disconnected. Their http client reports something like this:

the server unexpectedly dropped the connection…

and nothing else is available. The error, server-side, is the same initgroups error as above, and it does not help at all. How would you solve this? truss is your friend.

Where I fix it

One thing I love about FreeBSD is the availability of many powerful tools out of the box. When I need to track down a strange software behavior, I feel very comfortable on FreeBSD (it doesn’t mean I’m skilled). truss is one of my favorites, it’s simple, straightforward and powerful.
What you need to use truss is the PID of your target. With Apache + MPM-ITK, processes won’t stay around very long, and you can’t tell which one you will connect to in advance. So the first step is to buy yourself some precious seconds so that you can get the PID of your target before the httpd process dies. Remember, it dies as soon as the .htaccess file is parsed. Being in production, I could not just kill everything and play alone with the server, so I choose another way. I’ve created a php script that would run for few seconds before ending. Server side, I’ve prepared a shell command that would install the .htaccess file I need to test, and start truss while grabbing the PID of my target. On FreeBSD, something like this should do the trick:

cd /path/to/user1/web/site
mv .htaccess_inactive .htaccess && truss -p $(ps auxw|awk '/^user1/ {print $2}')

First http GET request, the .htaccess file is not present, an httpd process switches from root to user1, starts serving the php script. I launch my command server-side: it puts .htaccess in place, gets the PID of my httpd process, and starts truss.
The php script ends and returns its result, client-side I refresh immediately (second GET request), so that I stay on the same httpd process. My client is disconnected as soon as the httpd process has parsed the .htaccess file. At this point, truss should already be dead. I’ve the complete trace of the event. The best is to read the trace backward from the point where httpd process issue an error about changing UID or GID:

01: setgroups(0x3,0x80a8ff000,0x14,0x3,0x566bc0,0x32008) 
    ERR#1 'Operation not permitted'
02: getgid()					 = 80 (0x50)
03: getuid()					 = 8872 (0x22a8)
04: getpid()					 = 52942 (0xcece)
05: gettimeofday({1364591872.453335 },0x0)		 = 0 (0x0)
06: write(2,"[Fri Mar 29 22:17:52 2013] [warn"...,142) = 142 (0x8e)
07: gettimeofday({1364591872.453583 },0x0)		 = 0 (0x0)
08: write(2,"[Fri Mar 29 22:17:52 2013] [warn"...,85) = 85 (0x55)
09: gettimeofday({1364591872.453814 },0x0)		 = 0 (0x0)
10: shutdown(51,SHUT_WR)				 = 0 (0x0)

Line 01 is the one I’m looking for: the httpd process is trying to change groups and fails, line 02 to 05 it’s gathering data for the log entry, line 06 it’s writing the error to the log file. 07 & 08: same deal for the second line of log.

From that point in time, moving up shows that it tried to access an out-of-directory resource, and that resource is an html error page! Of course, it makes sense, and it’s an hard slap on the head (RTFM!).

01: stat("/user/user1/public_html/bench.php",{ 
    mode=-rw-r--r-- ,inode=4121,size=7427,blksize=7680 }) = 0 (0x0)
02: open("/user/user1/public_html/.htaccess",0x100000,00) = 53 (0x35)
03: fstat(53,{ mode=-rw-r--r-- ,inode=4225,size=128,blksize=4096 }) = 0 (0x0)
04: read(53,"AuthType Basic\nAuthName "Admin "...,4096) = 128 (0x80)
05: read(53,0x80a8efd88,4096)			 = 0 (0x0)
06: close(53)					 = 0 (0x0)
07: open("/user/user1/public_html/bench.php/.htaccess",0x100000,00) 
    ERR#20 'Not a directory'
08: getuid()					 = 8872 (0x22a8)
09: getgid()					 = 80 (0x50)
10: stat("/usr/local/www/apache22/error/HTTP_UNAUTHORIZED.html.var",{ 
    mode=-rw-r--r-- ,inode=454787,size=13557,blksize=16384 }) = 0 (0x0)
11: lstat("/usr/local/www/apache22/error/HTTP_UNAUTHORIZED.html.var",{ 
    mode=-rw-r--r-- ,inode=454787,size=13557,blksize=16384 }) = 0 (0x0)
12: getuid()					 = 8872 (0x22a8)
13: setgid(0x50,0x805d43d94,0x64,0x800644767,0x101010101010101,0x808080808080
    8080) = 0 (0x0)

line 13 shows the beginning of setgid process, and 10/11 shows the culprit. Up from here is the regular processing of the .htaccess file.

RTFM

When you use mod_auth* to present visitors with authentication, the server issues an error, and most of the time, this error is sent to the client with a dedicated header, and a dedicated html document (think “404″). When the error is about authentication (error 401), most clients hide the html part, and present the user with an authentication popup.
But the html part is almost always a physical file somewhere in the server directory tree. And it’s this particular file the httpd process was trying to reach, issuing an initgroups command, and dying for not being allowed to switch users.
I’ve found in my Apache config the definition of ErrorDocument:

ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var
ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var
ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var
...

and replaced them all by a file-less equivalent, so Apache won’t have any error file to read and will just send a plain ASCII error body (it saves bandwidth too):

ErrorDocument 400 "400 HTTP_BAD_REQUEST"
ErrorDocument 401 "401 HTTP_UNAUTHORIZED"
ErrorDocument 403 "403 HTTP_FORBIDDEN"
...

I’ve restarted Apache, and authentication from mod_auth* started to work as usual.
Same approach applies to almost any mpm-itk problem when it’s related to a connection loss with Couldn't set uid/gid/priority, closing connection error log. You locate the resource that makes your server fail, and you find a way to fix the issue.

Nuxeo contre Alfresco

Après un mois d’utilisation du logiciel de GED Nuxeo DM, le bilan est plutôt négatif. Je pensais naïvement avoir mis la main sur une application correcte (comme elle est en JAVA, elle peut tout au plus être correcte). Un pré-requis très important pour moi était la possibilité d’utiliser MySQL comme moteur de base de données. En réalité, bien que Nuxeo supporte MySQL officiellement, l’usage de ce moteur est absolument découragé. Les développeurs listent une série de raisons somme-toute valables, et qui peuvent se résumer comme ceci : il aurait fallu coder Nuxeo pour qu’il supporte les spécificités de MySQL, et on a eu la flemme. En réalité, rien ne fonctionne vraiment correctement si on utilise Nuxeo avec MySQL. À tel point qu’il ne devrait même pas être possible de choisir ce serveur de base de données dans les menus de configuration de Nuxeo. Et c’est bien ça qui me met en rogne. J’ai perdu un mois, et de nombreuses heures de travail pour un logiciel qui oscille finalement entre le “peu fiable” et le “carrément inutilisable”.
Entre alors en scène Alfresco. Un logiciel concurrent, codé lui aussi en (wait for it) JAVA. Ce dernier fonctionne très bien avec MySQL, je l’ai donc installé sans tarder pour me faire une opinion sur ses capacités. Les différences avec Nuxeo sont importantes.
Continue reading

Installation de Nuxeo DM sur FreeBSD, épisode 3

Avec un peu de travail, Nuxeo DM peut être abrité en HTTPS derrière un serveur Apache. Je fais l’impasse sur la configuration interne à Nuxeo, elle se fait très simplement à la première connexion via l’assistant fourni. Si vous êtes arrivés jusque là, il ne manque plus qu’un script de démarrage pour que tout fonctionne de manière transparente sur votre serveur.
Voici le contenu du script de lancement/arrêt pour une instance de Nuxeo DM, /usr/local/etc/rc.d/nuxeo. N’oubliez pas de remplacer la valeur de nuxeo_home par le chemin de votre répertoire nuxeo :

#!/bin/sh

# PROVIDE: nuxeo
# REQUIRE: DAEMON
# BEFORE: LOGIN

# Define these nuxeo_* variables in one of these files:
#       /etc/rc.conf
#       /etc/rc.conf.local
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
nuxeo_enable="${nuxeo_enable-NO}"
nuxeo_user="${nuxeo_user-nuxeo}"
nuxeo_home="/CHEMIN/DE/nuxeo"

. /etc/rc.subr

name="nuxeo"
rcvar=`set_rcvar`
start_cmd=${name}_start
stop_cmd=${name}_stop

nuxeo_start()
{
cd $nuxeo_home
$nuxeo_auditflags sudo -u $nuxeo_user ./bin/nuxeoctl startbg
}

nuxeo_stop()
{
cd $nuxeo_home
sudo -u $nuxeo_user ./bin/nuxeoctl stop
}

load_rc_config $name

run_rc_command "$1"

Une fois le fichier créé, rempli, et rendu exécutable, il faut ajouter ces quelques lignes à votre fichier /etc/rc.conf :

nuxeo_enable="YES"
nuxeo_user="NUXEO_USER"

Vous remplacerez bien sûr NUXEO_USER par le nom du compte utilisateur qui fera tourner l’application Nuxeo DM. Après cela, les commandes /usr/local/etc/rc.d/nuxeo restart, /usr/local/etc/rc.d/nuxeo stop et /usr/local/etc/rc.d/nuxeo start doivent fonctionner.
Attention, suivant la puissance de votre machine, et l’état de remplissage de Nuxeo, le temps de lancement peut varier énormément.

Côté mise à jour, vous pouvez accéder aux “hotfix” officiels, gratuitement pendant 30 jours, moyennant une inscription sur le site web de Nuxeo. L’inscription se passe facilement, par contre les mise à jour sont délicates et nécessitent de suivre scrupuleusement les instructions du support Nuxeo. Notamment, relancez bien l’application entre chaque mise à jour.

Installation de Nuxeo DM sur FreeBSD, épisode 2

Une application Tomcat ne devrait pas se trouver nue sur internet. J’ai pour habitude de toujours placer un frontal Apache devant. Cela autorise divers améliorations du service. Apache peut par exemple gérer l’authentification des utilisateurs, faire une balance de charge entre plusieurs instances de l’application, etc. Il permet aussi à votre application d’être joignable sur les port HTTP(S) standard (80 et 443) sans que l’application doive être lancée en root (et sans recourir à une redirection dans votre firewall).

Il existe plusieurs moyens de présenter Nuxeo DM au travers d’un proxy Apache. J’ai choisi d’utiliser mod_proxy. Avec mod_proxy, la configuration est assez standard. Tout, ou presque, est réglé en 3 lignes si on se contente de l’HTTP. Mais pour sécuriser mes connexions à Nuxeo, qui contiendra mes documents personnels et confidentiels, j’ai décidé d’utiliser HTTPS.
J’ai donc un virtual host Apache, et un certificat SSL associé, dans le quel j’inclue les directives de mod_proxy.

<VirtualHost IP.DU.SER.VEUR:443>
   ServerName DOMAINE.TLD:443
   UseCanonicalName On
   DocumentRoot "/chemin/de/nuxeo/"

   SSLEngine on
   #... config SSL ...

   RequestHeader append nuxeo-virtual-host "https://DOMAINE.TLD/"
   <IfModule proxy_module>
     ProxyRequests Off
     <Proxy *> 
        Order deny,allow
        Allow from all
     </Proxy> 
     ProxyPass /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPassReverse /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPreserveHost On
   </IfModule>

</VirtualHost>

Ça c’est d’après la documentation. En réalité, ce n’est pas suffisant. Tout d’abord, il faut bien placer la directive RequestHeader à l’extérieur du bloc proxy_module, sinon elle est juste ignorée par le serveur. Il ne m’a pas fallu moins qu’un tcpdump pour localiser le problème.
J’ai aussi constaté qu’avec ces directives, la première connexion à l’application se fait bien, puis on est immédiatement redirigé vers le même virtual host mais sur le port 80. Je règle le problème avec une directive de redirection dans le vhost http :

<VirtualHost *>
    ServerName DOMAINE.TLD
    DocumentRoot /chemin/de/nuxeo
    Redirect / https://DOMAINE.TLD/ 
</VirtualHost>

Ce n’est pas totalement satisfaisant, mais faute de mieux, cela fonctionne parfaitement.
En relançant Apache à ce stade, on obtient un proxy fonctionnel et sécurisé par SSL pour Nuxeo.

Avant d’aller plus loin, on peut prendre quelques minutes pour créer une base de données MySQL (ou autre) et un utilisateur MySQL associé à cette base. C’est ce compte de base de données qu’il faudra fournir au moment de la configuration de Nuxeo.

Je fais totalement l’impasse sur la configuration de Nuxeo DM dans le “wizard”, elle est bien documentée, et plutôt simple. Il suffit de lancer l’application par la commande ad-hoc si ce n’est pas déjà fait :

# cd /chemin/du/répertoire/nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg

Ensuite on se connecte à l’adresse https://DOMAINE.TLD/nuxeo et on peut entamer la configuration.

Installation de Nuxeo DM sur FreeBSD, épisode 1

J’ai récemment choisi Nuxeo DM comme application de GED. C’est une application en JAVA, tournant dans un serveur d’application Tomcat. Nuxeo est packagé sous différentes formes, une seule est utilisable sur FreeBSD : Nuxeo DM Tomcat bundle.
L’installation de Nuxeo sur FreeBSD nécessite trois choses : installer les pré-requis logiciels, configurer l’environnement pour sécuriser l’application, et configurer l’application elle-même.

Côté pré-requis, il faut tout d’abord installer le Java Runtime Environment, et le Java Development Kit. Sous FreeBSD, il faut donc installer les ports java/diablo-jdk16 et java/diablo-jre16. Pour une question de licence, il faut télécharger à la main les packages nécessaires chez Oracle. Il suffit simplement de suivre les instructions obtenues pour chaque port au moment du make. Par exemple :

$ cd /usr/ports/java/diablo-jdk16/
$ make
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for diablo-jdk-1.6.0.07.02_12

 Because of licensing restrictions, you must fetch the distribution
 manually.

 Please open http://www.oracle.com/technetwork/java/javase/downloads/index.html
 in a web browser and follow the "Download" link for
 "JDK DST Timezone Update Tool - 1_3_42" to obtain the
 time zone update file, tzupdater-1_3_42-2011k.zip.

 Please place the downloaded file(s) in /usr/ports/distfiles.
 ...

Une fois les ports java/diablo-jdk16 et java/diablo-jre16 installés, il faut installer un serveur web comme Apache 2.2, un serveur de bases de données (MySQL ou PostgreSQL par exemple), et à minima pdftohtml. Il est aussi possible d’installer OpenOffice, mais comme il n’existe pas de version “headless” dans les ports de FreeBSD, cela vous embarque dans l’installation complète avec gestionnaire de fenêtre et tutti quanti. Une calamité.
Pour utiliser l’application sur une connexion sécurisée (HTTPS), il faut qu’Apache dispose d’un certificat SSL adéquat.

Quand tout ceci est installé et configuré, il faut encore ajouter un compte utilisateur pour l’application Nuxeo. Les paresseux pourront la faire tourner sous le compte www. J’ai préféré un utilisateur indépendant, plus facile à tracer via auditd et l’accounting.

On peut alors télécharger et décompresser le package multiplateforme à partir du site internet de Nuxeo. On obtient un répertoire nommé nuxeo-dm-5.4.2-tomcat. J’ai pour habitude d’exploiter une application à partir d’un répertoire ne portant pas de numéro de version. On aura intérêt à renommer ce répertoire en nuxeo, car ici, faire un lien symbolique de nuxeo-dm-5.4.2-tomcat vers nuxeo ne donne pas vraiment satisfaction.
Pour en finir avec les fichiers, il faut faire un chown -R sur le répertoire nuxeo pour que les fichiers appartiennent tous à l’utilisateur non privilégié que l’on a créé plus haut.

Ensuite, comme nous sommes sur FreeBSD et pas Linux, il faut revoir certains scripts shell. Ces derniers ont un shebang qui pointe vers /bin/bash alors que notre bash est dans /usr/local/bin/. Les scripts à modifier sont les suivants : bin/monitorctl.sh, bin/nuxeoctl, bin/pack.

Arrivé là, il est intéressant de lancer l’application via la ligne de commande pour tester qu’au moins elle se lance et répond sur le port 8080 :

# cd nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg
...
No current configuration, generating files...
Configuration files generated.
Server started with process ID 1438.

Le serveur est lancé, et il écoute bien sur le port 8080 :

# netstat -alnf inet | grep 8080
tcp4       0      0  *.8080                 *.*                    LISTEN

Ce que l’on peut aisément vérifier avec un client HTTP en ligne de commande, ou un coup de telnet :

$ curl http://127.0.0.1:8080
<META HTTP-EQUIV="refresh" CONTENT="0;URL=/nuxeo">

On a maintenant une application Tomcat/Java qui tourne sur notre serveur FreeBSD, sous un compte utilisateur dédié. Il reste à brancher devant un proxy Apache HTTPS, créer un script de démarrage automatique pour l’application, et configurer cette dernière.

La suite au prochain épisode :)

Utiliser auditd sur Mac OS X et FreeBSD – 3

Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD – 2

Exploiter les résultats de l’audit

Dans le premier article j’ai mentionné très succinctement une commande qui permet de lire les logs d’audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n’a envie d’activer l’audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d’être : pouvoir ensuite (ou en temps réel) exploiter les logs d’auditd. Continue reading