5504 links
  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
page 1 / 1
9 results for BMC
  • De Debian GNU/Linux Jessie à Stretch

    Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Stretch.

    Nommage des interfaces réseau

    Désormais, les interfaces réseau portent des noms dit cohérents. Soit tu mets à jour ton fichiers interfaces, soit tu désactives ce nouveau nommage. Attention si tu bosses sur des machines distantes en adressage static : ne rebootes pas avant d'avoir fait une modif' ;) .


    dictionaries-common/default-ispell

    Sur une seule de mes machines, celle équipée d'aspell (pour Roundcube via php-pspell), le message suivant s'est affiché durant la mise à jour :

    Base de données de configuration probablement corrompue

    Le réglage pour « dictionaries-common/default-ispell»  est manquant mais des paquets fournissant des candidats pour ce réglage sont installés : « ifrench-gut ».

    Cela peut être dû à une corruption de la base de données de configuration (« debconf »). Veuillez consulter le fichier (non traduit en français) /usr/share/doc/dictionaries-common/README.problems au chapitre « Debconf database corruption ». │

    Dans cette situation, il est possible d'exécuter la commande « /usr/share/debconf/fix_db.pl » pour remettre la base de données de configuration dans un état cohérent.

    Il est probable que certaines questions seront alors posées afin de replacer le système de gestion des dictionnaires dans un état (temporairement) opérationnel.

    À la fin de la mise à jour, j'ai exécuté /usr/share/debconf/fix_db.pl avec succès puis j'ai vérifié : les paquets ispell et ifrench-gut ne sont pas installés… Erreur transitoire ?


    OpenSSH

    Les paramètres « RSAAuthentication » et « RhostsRSAAuthentication » sont dépréciés d'où un message s'affiche dans le log.


    Postfix

    Postfix passe en version 3.X. Elle apporte un filet de sécurité qui prévient, dans le log, des réglages implicites qui ont changé. Exemple : dans cette nouvelle version, les diffférents modules (nommés services) de Postfix ne sont plus exécutés dans un chroot par défaut. Dans mon fichier master.cf, dans la colonne « chroot », il y a la valeur implicite « - » qui signifiait « yes » avant et « no » maintenant donc Postfix émet un avertissement dans le log : /etc/postfix/master.cf: line 36: using backwards-compatible default setting chroot=y pour chaque service configuré.

    Comme je suis certain de vouloir chrooter les services Postif (car ça a toujours bien fonctionné ainsi…), je mets toute la colonne « chroot » à « y » à l'exception des services local, pipe, spawn, virtual et proxymap puis je redémarre Postfix. Notons qu'une commande de type postconf -F <nom_service>/<type>/chroot=y pour chaque service produira le même résuultat (mise à « y » dans master.cf).


    Dovecot

    Dans la configuration de tous mes services réseau, je désactive explicitement SSLv2 et SSLv3. Avec Dovecot, cela donne ssl_protocols = !SSLv2 !SSLv3.

    Or, les devs OpenSSL ont (enfin !) totalement désactivé SSLv2 entre la version 1.0.2h et 1.1.0 (voir /usr/share/doc/openssl/changelog.gz). Ainsi, le symbole « SSLv2 » n'existe plus, donc Dovecot retourne l'erreur : imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'. Notons que d'autres logiciel, comme Postfix, ne remontent pas d'erreur quand on interdit l'usage de SSLv2 dans leur config'. J'imagine que cette diffférence provient de la manière d'appeler les fonctions de la lib OpenSSL…

    La correction est simple : dans la conf' de Dovecot, je n'utilise plus que : ssl_protocols = !SSLv3.


    Sympa

    Après la mise à jour, le menu de l'interface web (« connexion », « assistance/documentation », « chercher une liste/index des listes », etc.) n'était plus cliquable : dès que j'essayais de cliquer sur un sous-item du menu, pouf, le menu se ferme. Idem pour la connexion : impossible de saisir mon identifiant et mon mot de passe.

    La raison est que j'utilise une configuration Apache httpd un peu plus contraignante que celle fournie par défaut avec Sympa (voir /etc/apache2/conf-available/sympa.conf ). Notamment, dans le dossier /var/lib/sympa/static_content, j'autorise le suivi des liens symboliques uniquement si le propriétaire du lien est le même que la destination du lien (« +SymLinksIfOwnerMatch »). Or, dans dans /var/lib/sympa/static_content, on trouve, par exemple external/jquery* qui est un lien symbolique root:root qui pointe vers un fichier sympa:sympa. Apache httpd ne le suivra donc pas. Or, en 2017, il faut obligatoirement du JS pour faire fonctionner un menu… Ceci explique cela.

    Changer le propriétaire du lien ne résistera pas à une prochaine mise à jour. Il vaut donc mieux supprimer « +SymLinksIfOwnerMatch » des « Options » du dossier.


    Langue

    Sympa dispose de plusieurs paramètres pour adapter la langue. « lang » dans la conf' permet de changer la langue par défaut des mails envoyés automatiquement. Chaque utilisateur peut également configurer sa langue dans ses préférences dans l'interface web.

    Quant à la langue par défaut de l'interface web (quand on ne s'authentifie pas), ça reste un mystère pour moi… Elle s'adapte à la langue annoncée par le navigateur web du visiteur grâce à l'entête HTTP « Accept-Language ». Avec mon Firefox packagé dans Debian configuré en Français, l'interface reste en anglais. Pourtant, Firefox annonce bien FR-fr puis en-US puis en… En revanche, si dans les préférences Firefox, Contenu, Langues, je supprime toutes les langues sauf le français, l'interface web de Sympa s'affiche en français. Avec curl, qui n'envoie pas l'entête « Accept-Language », l'interface est en français… Est-ce un bug de Firefox qui annonce mal la priorité de chaque langue supportée ou un bug de Sympa qui interprête mal les différente langues supportées par un navigateur web ? Aucune idée…


    PHP 7

    PHP 7 est installé durant la mise à jour, mais il n'est pas forcément activé… et comme la sécurité de PHP 5 n'est plus prise en charge dans cette version de Debian, je pense qu'il vaut mieux cesser de l'utiliser et passer en 7.0.

    D'abord, il faudra porter ta configuration de /etc/php5 vers /etc/php. Par exemple, dans mes php.ini, je modifie toujours les valeurs des paramètres disable_functions, openssl.cafile, memory_limit, html_errors, post_max_size, date.timezone, session.save_path (pour pointer sur un RAMdisk / tmpfs). Elles ne sont pas importées automatiquement dans la nouvelle configuration.

    Il faut désactiver PHP 5 avec a2dismod php5 puis virer les paquets php5-* et libapache2-mod-php5 puis vérifier que libapache2-mod-php7.0 et les modules php-* (oui, on note l'apparition de ces metapaquets) correspndant aux php5-* désactivés sont bien installés. Enfin, il faut activer PHP 7 avec a2enmod php7.0 && systemctl restart apache2.

    Il faut vérifier que tous tes sites web fonctionnent. S'il n'y a pas de doute à avoir avec les logiciels packagés dans Debian (c'est tout l'intérêt d'une distribution), il n'en va pas de même avec les extensions ni avec les logiciels installés en dehors du gestionnaire de paquets. Exemple : j'utilisais l'extension WordPress ContentOverSSL. Celle-ci utilise la fonction PHP ereg qui a été supprimée dans PHP 7.0. Si tes logs sont bien fichus, tu devrais y trouver les fonctions problèmatiques, genre PHP Fatal error: Uncaught Error: Call to undefined function ereg() in </chemin/vers/fichier.php>.


    PHP 7 + TLS dans un chroot

    Attention, un chroot Apache httpd incomplet ne pardonne plus avec PHP 7.0. En effet, mon chroot ne contenait pas /dev/random et /dev/urandom et un file_get_contents('https://shaarli.guiguishow.info'); sortait en erreur :

    PHP Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
    \nerror:24064064:random number generator:RAND_bytes:PRNG not seeded in /var/www/shaarli/test.php on line 2
    PHP Warning: file_get_contents(): Failed to enable crypto in /var/www/shaarli/test.php on line 2
    PHP Warning: file_get_contents(https://shaarli.guiguishow.info): failed to open stream: operation failed in /var/www/shaarli/test.php on line 2

    Pour réparer :

    mkdir $chrootdir/dev
    mknod /var/apache/chroot/dev/random c 1 8
    mknod /var/apache/chroot/dev/urandom c 1 9
    systemctl restart apache2


    MySQL

    La mise à jour et le passage à MariaDB se passe bien… sauf si l'on utilise un chroot.

    En premier lieu, j'ai eu une erreur relative à /usr/share/mysql/errmsg.sys. J'y suis habitué : il faut copier ce fichier dans le chroot.

    Ensuite, j'ai eu l'erreur InnoDB: ./ib_logfile0 can't be opened in read-write mode. Le web conseille de supprimer ib_logfile0 et ib_logfile1.

    ENfin, j'ai eu les erreurs InnoDB: Could not find a valid tablespace file for 'mysql/gtid_slave_pos'., InnoDB: Could not find a valid tablespace file for 'mysql/innodb_index_stats'., InnoDB: Could not find a valid tablespace file for 'mysql/innodb_table_stats'..

    J'ai essayé de terminer le script /usr/scripts/scripts/mysql_install_db, mais il était impossible de lancer MySQL, même avec les fichiers ib_logfile* remis à leur place et le mode safe…

    Dès l'origine, j'ai configuré salement ce chroot, avec des liens symboliques (et d'autres choses qu'il ne faut pas faire avec un chroot) afin de contenter MySQL. Il m'apparaît, plus de 5 ans après, que le fonctionnement dans un chroot n'est pas vraiment bien intégré dans MySQL en comparaison d'Apache ou de Postfix (la copie du fichier errmsg.sys en est une illustration). Je pense que ce chroot m'apporte plus d'ennuis que de sécurité. Donc, j'ai décidé de le supprimer. J'ai donc déinstallé MySQL (en répondant non à la question "faut-il supprimer l'ensemble des bases de données ?"), j'ai viré tout ce qui est relatif à MySQL de mon arborescence, à l'exception de /var/lib/mysql. J'ai installé MySQL et… ça a fonctionné. \o/


    Logrotate

    La nuit suivant cette ré-installation de MySQL, logrotate a terminé en erreur :

    /etc/cron.daily/logrotate:
    mysqladmin: connect to server at 'localhost' failed
    error: 'Access denied for user 'root'@'localhost' (using password: NO)'
    error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
    run-parts: /etc/cron.daily/logrotate exited with return code 1

    La solution se trouve ici : il faut saisir le mot de passe de l'utilisateur de la base de données « debian-sys-maint » dans /etc/mysql/debian.cnf. Si tu ne le connais plus, connectes-toi en root à la base de données puis change-le avec SET PASSWORD FOR 'debian-sys-maint'@'localhost' = PASSWORD('<nouveau_mdp>');.


    RoundCube

    Durant l'installation, dbconfig produisait des erreurs du genre "je n'arrive pas à me connecter à la base de données" mais en beaucoup moins trivial (la base de données fonctionnait et le message d'erreur était plus cryptique que ce que j'en rapporte ici). J'ai décidé de quitter dbconfig sans rien configurer. Une fois la mise à jour terminée, roundcube ne savait plus pour quels domaines il devait répondre… Je l'ai reconfiguré avec dpkg-reconfigure roundcube-core et tout est devenu OK.


    OpenDKIM

    Dans mes logs, OpenDKIM s'écrivait milter socket must be specified tandis que systemd s'écrivait opendkim.service: PID file /var/run/opendkim/opendkim.pid not readable (yet?) after start: No such file or directory

    Dans Stretch, OpenDKIM abandonne son script sysvinit et utilise une unit systemd. /etc/default/opendkim n'est donc plus lu. Il faut donc indiquer la socket directement dans la configuration d'OpenDKIM (/etc/opendkim.conf).

    De même, systemd s'attend à obtenir le PID d'OpenDKIM dans le fichier /var/run/opendkim/opendkim.pid . Il faut donc ajouter PidFile /var/run/opendkim/opendkim.pid dans /etc/opendkim.conf.

    Dans le modèle de configuration qui nous est proposé, remarquons la directive « UserID » qui permet de ne plus exécuter OpenDKIM en root.


    OpenDNSSEC

    OpenDNSSEC passe de sa version 1.4.6 à sa version 2.0.4 donc, forcément, ça implique une importante migration. Migration assez mal préparée dans le paquet Debian puisque le message nous indique « The enforcer does require a full migration, as the internal database has been completely revised. See the upstream documentation in the /usr/share/opendnssec/1.4-2.0_db_convert/README.md » alors que le dossier /usr/share/opendnssec/1.4-2.0_db_convert/ est vide et les fichiers nécessaires sont éparpillés dans /usr/share/opendnssec… … …

    Bref, voici comment j'ai mis à jour :

    • Vérifie qu'une clé n'est pas en train d'être changée ou d'être préparée à l'être : echo 'SELECT zones.name FROM dnsseckeys JOIN zones on zones.id = dnsseckeys.zone_id WHERE dnsseckeys.keytype = 257 AND dnsseckeys.active IS NULL AND dnsseckeys.zone_id NOT IN (SELECT dnsseckeys.zone_id FROM dnsseckeys WHERE dnsseckeys.keytype = 257 AND dnsseckeys.state = 4);' | slite3 /var/lib/opendnssec/kasp.db . Si c'est le cas, la doc' d'OpenDNSSEC conseille d'attendre que le rollover soit terminé pour mettre à jour ;

    • Récupére le KeyTag de tes clés actuelles avec ods-ksmutil key list --verbose ;

    • Fais une copie de /var/lib/opendnssec/kasp.db et /var/lib/softhsm/slot0.db , ça te permettra de rollback. Testé et approuvé ;) ;

    • On arrête toute la machinerie et on l'empêche de démarrer durant la mise à jour :

      systemctl stop opendnssec-enforcer.service
      systemctl stop opendnssec-signer.service
      systemctl disable opendnssec-enforcer.service
      systemctl disable opendnssec-signer.service
      systemctl mask opendnssec-enforcer.service
      systemctl mask opendnssec-signer.service
      systemctl mask opendnssec-signerd.service


    • Procéde à la mise à jour du système… Conserve les fichiers de conf' actuels d'OpenDNSSEC ;

    • Mets à jour le schéma de la base de données d'OpenDNSSEC vers celui de la version 1.4.8 : cat /usr/share/opendnssec/migrate_1_4_8.sqlite3 | sqlite3 /var/lib/opendnssec/kasp.db ;

    • Mets à jour le contenu de la base de données d'OpenDNSSEC de la version 1.X à 2.X :

      cd /usr/share/opendnssec/
      ./convert_sqlite -i /var/lib/opendnssec/kasp.db -o /var/lib/opendnssec/kasp.db.new
      mv /var/lib/opendnssec/kasp.db.new /var/lib/opendnssec/kasp.db


    • Retrouve la cohérence des KeyTags suite à la migration : ods-migrate ;

    • Évite l'erreur « ods-signerd[27373]: [file] unable to stat file /var/lib/opendnssec/enforcer/zones.xml: ods_fopen() failed » : cp /etc/opendnssec/zonelist.xml /var/lib/opendnssec/enforcer/zones.xml ;

    • Démarre l'enforcer et vérifie que tes clés sont toujours là (à l'aide des KeyTags mis de côté au début ;) ) :

      ods-enforcer start
      ods-enforcer key list --verbose


    • Si tout est OK, démarre le signer et tente de signer une modification de ta zone DNS :

      ods-signer start
      <Fais une modification de ton fichier de zone ici>
      ods-signer sign <nom_zone>
      <Vérifie que ta modification est effective>


    • Si tout est OK, on re-active le lancement d'OpenDNSSEC au boot :

      ods-signer stop
      ods-enforcer stop
      systemctl unmask opendnssec-signerd.service
      systemctl unmask opendnssec-signer.service
      systemctl unmask opendnssec-enforcer.service
      systemctl enable opendnssec-enforcer.service
      systemctl enable opendnssec-signerd.service
      systemctl start opendnssec-enforcer.service
      systemctl start opendnssec-signer.service


    Changement dans les conf'

    • conf.xml :

      • Enforcer / « Interval » n'est plus utilisé et est déprécié dès la version 2.1 ;

      • Enforcer / ajout de « P1Y » : pré-génère les paires de clés nécessaires pour couvrir un an dès l'ajout d'une zone ;

      • Enforcer / ajout de « /var/lib/opendnssec/enforcer » ;

      • Signer / changement de la valeur de « WorkingDirectory » pour « /var/lib/opendnssec/signer » ;
    • kasp.xml :

      • Les zones ont désormais un paramètre « MaxZoneTTL » avec une valeur par défaut d'un jour. Si la zone contient des enregistrements plus grands que la valeur de ce paramètre, ils seront cappés.
    • zonelist.xml n'est plus vraiment utilisé et est remplacé par des commandes qui interrogent la base de données interne.


    SoftHSM

    SoftHSM passe lui aussi d'une version 1.X à 2.X, donc une migration nous attend. Notons que cette migration n'est pas obligatoire à mon sens, car le paquet softhsm version 1.X est toujours maintenu dans cette version de Debian.

    Voici comment j'ai procédé :

    • Évite l'erreur « ERROR: Could not initialize the library. » : mkdir /var/lib/softhsm/tokens ;

    • Créer un nouveau coffre-fort dans la nouvelle version de SoftHSM : softhsm2-util --init-token --slot 0 --label OpenDNSSEC ;

    • Copie l'ancien coffre-fort dans le nouveau : softhsm2-migrate --db /var/lib/softhsm/slot0.db --token OpenDNSSEC ;

    • Fais utiliser SoftHSM2 par OpenDNSSEC en modifiant la section « Repository » de /etc/opendnssec/conf.xml : <Module>/usr/lib/softhsm/libsofthsm.so</Module> devient <Module>/usr/lib/softhsm/libsofthsm2.so</Module>. Change le PIN si t'as configuré un nouveau USER PIN sur le coffre-fort version 2 ;

    • Redémarre OpenDNSSEC et vérifie que tout est OK ;

    • Si tout est OK, tu peux virer la version 1.X de SoftHSM : apt-get autoremove --purge softhsm-common softhsm.


    Si besoin de rollback

    • Coupe tout OpenDNSSEC et empêche-le de démarrer automatiquement durant le rollback :

      systemctl stop opendnssec-enforcer.service
      systemctl stop opendnssec-signer.service
      systemctl disable opendnssec-enforcer.service
      systemctl disable opendnssec-signer.service
      systemctl mask opendnssec-enforcer.service
      systemctl mask opendnssec-signer.service
      systemctl mask opendnssec-signerd.service


    • Copie tes sauvegardes des fichiers /var/lib/opendnssec/kasp.db et /var/lib/softhsm/slot0.db à leur emplacement d'origine ;

    • Ajoute les dépôts Jessie dans ton sources.list et réinstalle la précédente version : apt-get install opendnssec=1:1.4.6-6 softhsm=1.3.7-2+deb8u1 opendnssec-enforcer-sqlite3=1:1.4.6-6 opendnssec-signer=1:1.4.6-6 opendnssec-common=1:1.4.6-6 libhsm-bin=1:1.4.6-6 opendnssec-enforcer=1:1.4.6-6 libsofthsm=1.3.7-2+deb8u1 softhsm-common=1.3.7-2+deb8u1 ;

    • Recommence la migration à tête reposée en vérifiant que tu n'as rien oublié.


    ejabberd

    Le bug que je rencontrais lorsque je spécifiais des suites de chiffrement PFS à utiliser lors des connexions c2s (client to server) a disparu.

    De même, cette version autorise enfin des dhparam > 1024 (directives « dhfile » et « s2s_dhfile »).

    J'ai remarqué de nombreux changements entre ma config' et celle qui est proposée par le paquet. Exemples :

    max_user_sessions:
    all: 10

    devient :

    max_user_sessions: 10


    max_user_offline_messages:
    admin: 5000
    all: 100

    devient :

    max_user_offline_messages:

    • 5000: admin
    • 100

    Conclusion : j'ai décidé de ne pas avoir une conf' passoire et/ou une conf' qui peut se casser d'un rien donc j'ai accepté la conf' proposée et je l'ai adaptée à mes besoins.


    icedtea-8-plugin

    Les applets Java prennent enfin en charge TLS version 1.2. Utile pour les consoles à distance des BMC (même si Dell propose de l'HTML 5 depuis iDRAC 8).


    OpenVPN

    Il est désormais à nouveau possible de négocier la version de TLS utilisée. Cela permettra à court terme de forcer l'usage de TLS 1.2 / TLS 1.1 sans avoir à modifier la conf' des clients…


    Unbound

    On peut enfin activer qname minimisation, ce qui est une bonne nouvelle pour la vie privée.


    Apache httpd

    On peut enfin spécifier des dhparam personnalisés.

    Mon Dec 25 17:54:39 2017 - permalink -
    - http://shaarli.guiguishow.info/?q1iocQ
  • Quelques notes sur les BMC IBM Integrated Management Module

    Une BMC, c'est une carte contrôleur greffée à la carte mère d'un ordinateur (on trouve ça plutôt sur les serveurs) qui permet le management à distance (via Internet) de la bécane (accès console, reboot, monitoring bas niveau,...). C'est super utile en cas de panne ou de fausse manip' puisque ça évite de bouger au datacenter où les machines sont hébergées pour debug.

    Quelques notes sur les BMC IBM IMM :

    • Le login par défaut est « USERID ». Le mot de passe par défaut est « PASSW0RD » (0 est le chiffre zéro). On ne rappellera jamais assez qu'il faut se créer un nouveau compte avec le même niveau de droits et un mot de passe plus résistant puis supprimer le compte par défaut, surtout si la BMC est exposée sur Internet.

    • L'interface est très fluide, en comparaison d'un ILO 2 ou d'un iDRAC 6. C'est très agréable à utiliser.

    • Chez moi, avec un Firefox avec un profil tout propre sans aucune extension, les liens pour ouvrir la console me faisaient télécharger deux fichiers jnlp. Tout comme chez Dell, il faut ouvrir ces fichiers avec icedtea (sous GNU/Linux, au moins). Sauf que là, ça ne fonctionnait pas : Java n'arrivait pas à se connecter à la BMC pour télécharger le code Java supplémentaire à exécuter. Plus de problème en mettant à jour le firmware de la BMC à la version 1,51 (datée de mai 2016), la dernière disponible à ce jour : le lien me fait télécharger un unique fichier jnlp et il fonctionne.

    • La mise à jour du firmware, parlons-en : il faut 4 minutes après la demande de redémarrage de la BMC pour qu'elle recommence à ping. Il faut ajouter 6 minutes supplémentaires (soit 10 minutes au total) pour qu'elle recommence à répondre en SSH et via le web. Après la mise à jour, il faut effacer les cookies, le cache, enfin tout quoi, sinon une erreur s'affiche à la connexion : « Your session has been terminated due to account deletion, account disabled, session termination, or session inactivity. Click here to start a new session ».
    Mon Jun 5 18:06:39 2017 - permalink -
    - http://shaarli.guiguishow.info/?Yo8neg
  • Disabling TLS 1.0 results in connectivity issues for Dell Management Consoles on Windows Server 2008 R2 and 2012 | Dell US

    Soit un contrôleur iDRAC 8. Jusqu'à aujourd'hui, j'ai bossé exclusivement avec des iDRAC 6 mais bon, ça doit bien rien changer, non ? Comme d'hab, je lance la console virtuelle. Comme d'hab, je récupére un fichier « .jnlp ». Pour l'exécuter, sous Debian GNU/Linux Jessie (l'actuelle stable), il faut les packages openjdk-7-jre icedtea-7-plugin.

    Mais, cette fois-ci, l'exécution foire : « Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. ». La console java est juste imbitable donc allons-y pour exécuter en ligne de commande :

    $ javaws viewer.jnlp
    Attempted to download https://192.0.2.1:443/images/logo.gif, but failed to connect!
    Attempted to download https://192.0.2.1:443/software/avctKVMIOLinux64.jar, but failed to connect!
    Attempted to download https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar, but failed to connect!
    Attempted to download https://192.0.2.1:443/software/avctKVM.jar, but failed to connect!
    JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
    JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
    JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
    JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
    JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
    JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
    netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
    […]

    Hum, donc l'applet n'arrive pas à récupérer des libs et des ressources en HTTPS depuis la BMC et donc forcément, elle n'a aucun code à exécuter… Pourtant, depuis ma machine, un wget https://192.0.2.1:443/images/logo.gif fonctionne très bien.

    Sortons Wireshark. En utilisant l'applet java, on constate que la BMC interrompt directement la communication après la réception (ack) du message TLS « Client Hello ». Avec wget, aucun problème. Ça ne peut pas être un erreur de certificat puisque le serveur a refusé d'établir une session TLS avant même de transmettre son certif'. Dans ce type de cas, généralement, on est sur des grosses erreur bateau genre version de TLS ou suite d'algo de chiffrement/intégrité.

    Avec l'applet java, la version TLS demandée au serveur est TLS 1.0. Avec wget, la version TLS demandée est TLS 1.2. Huuum, sortons notre openssl :

    $ openssl s_client -connect 192.0.2.1:443 -tls1
    CONNECTED(00000003)
    140316040763024:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
    […]

    Hé oui, à partir d'iDRAC 7 ou 8 version 2.40.40 ou supérieure, TLS 1.0 est désactivé par défaut.

    Que faire ?

    • Activer la prise en charge de TLS 1.0 côté BMC en utilisant racadm : nope, nope, nope. La version 1.0 de TLS est une passoire et le fait que la BMC soit dans un VLAN isolé n'est pas un motif suffisant pour l'utiliser !

    • openjdk-8-jre et icedtea-8-plugin, dont on peut attendre une prise en charge de TLS 1.2 (ou au moins 1.1 :- ) ne sont dans dans Debian stable à l'heure actuelle. Je ne vais pas utiliser des packages de testing.

    • Se passer de Java. Surtout que les applets Java seront dépréciées dans Java 9. C'est possible à partir d'iDRAC 8 qui propose une version HTML 5 de la console virtuelle. Pour l'activer, il faut aller dans l'item « Console virtuelle » du menu « Présentation générale ». Il faut changer la valeur de « Type de plug-in » pour « HTML5 ».
    Tue Feb 21 17:16:56 2017 - permalink -
    - http://www.dell.com/support/article/us/en/04/SLN302365/disabling-tls-10-results-in-connectivity-issues-for-dell-management-consoles-on-windows-server-2008-r2-and-2012?lang=EN
  • technique:ganeti [Alsace Réseau Neutre] [ Split Brain (divergence entre deux disques DRBD) ]

    Suite au dernier problème rencontré sur l'infra d'ARN, je viens de mettre à jour cette page. On y parle des split-brain DRBD et de que faire lorsqu'un gnt-instance --cleanup reste bloqué Si ça peut aider des gens…

    En gros, voici ce qui s'est passé : je souhaitais appliquer la màj de sécurité de Linux ajoutée dans Debian 8.7. Je migre toutes les VMs sur le 2e hypeviseur, je màje le premier hyperviseur, je le reboot, il revient à la vie, les DRBD remontent, etc.

    Je migre toutes les VMs sur le 1er hyperviseur, je màj le deuxième hyperviseur, je reboot. Le deuxième hyperviseur revient à la vie, les premiers DRBD commencent à peine à remonter et là… perte de contrôle sur le premier hyperviseur : plus de SSH (pas même de SSHoIPv6), plus de ping (mais encore ping6 !) sur le lien d'interco direct entre les deux hyperviseurs, plus de BGP (IPv4 comme IPv6) entre les deux hyperviseurs, impossible d'obtenir un quelconque affichage sur la console virtuelle de la BMC, etc. Évidemment, rien dans les logs sinon ça rend le post-mortem trop facile.

    À ce stade, j'aurais pu tenter de mettre en sécurité les VMs dont le DRBD était remonté (pour autant qu'il y en ait eu, ce que je ne sais pas) en forçant le 2e hyperviseur à devenir le master puis en migrant les VMs sur ce 2e hyperviseur. Je n'y ai pas pensé.

    Vu l'ampleur du problème, je décide de forcer le redémarrage physique du premier hyperviseur avec la BMC. Je reprends la main dans la console de la BMC et via SSH.

    Tous les DRBD remontent et Ganeti démarre toutes les VMs… Mais, notre monitoring me remonte qu'un DRBD est dans un sale état : « 24: cs:WFBitMapS ro:Primary/Secondary ds:UpToDate/Consistent C r----- ».

    On est typiquement dans une conséquence d'un split-brain DRBD. Sauf qu'il est d'un type nouveau que nous n'avons pas encore documenté. C'est désormais chose faite. Notons qu'après coup, je ne suis pas satisfait de la solution car elle répond plutôt à la question « comment annuler un job dans l'état running ? » qu'à la question « comment résoudre ce type de split-brain ? ». Il aurait pu être intéressant de tenter un gnt-instance activate-disks plutôt qu'un gnt-instance --cleanup mais bon…

    Sat Jan 28 10:57:47 2017 - permalink -
    - https://wiki.arn-fai.net/technique:ganeti#split_brain_divergence_entre_deux_disques_drbd
  • Mettre à jour une BMC Dell ou HP

    Une BMC, c'est une carte contrôleur greffée à la carte mère d'un ordinateur (on trouve ça plutôt sur les serveurs) qui permet le management à distance de la bécane (accès console, reboot, monitoring bas niveau,...). Super utile en cas de panne ou de fausse manip' puisque ça évite de bouger au datacenter où les machines sont hébergées pour debug.

    Comme ces contrôleurs sont exposés sur Internet (adresse IP publique, interface web, SSH, etc.) et qu'ils permettent de grandes choses (reboot de la machine, accès à distance, etc.), il est important de les maintenir à jour. Cf http://shaarli.guiguishow.info/?-leLhg pour une étude du niveau actuel de délabrement.

    Pour un serveur Dell PowerEdge R710 avec iDRAC6, c'est par ici : http://www.dell.com/support/home/us/en/19/product-support/product/poweredge-r710/drivers , dans la catégorie « Embedded Server Management », « Dell iDRAC Monolithic Release X.XX ».

    Pour un serveur HP ProLiant DL380G6 avec un iLO 2, c'est par ici : http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=3884088&swLangOid=8&swEnvOid=4064 , dans la catégorie « Firmware - Lights-Out Management », « Online ROM Flash Component for Windows » ou pour winwin x64, ça n'a pas d'importance.

    Une fois l'exécutable téléchargé, on le décompresse avec 7zip, par exemple : 7z x ESM_Firmware_J7YYK_WN32_2.85_A00.EXE.

    Parmi les fichiers décompressés, on trouve :

    • Pour Dell : payload/firmimg.d6
    • Pour HP : ilo2_<version>.bin

    Il suffit d'uploader ces firmwares en utilisant l'interface web de la BMC pour que la mise à jour se fasse.

    Les BMC, c'est un truc auquel on pense rarement. Il faut donc se tenir informé par RSS ou par mail de la sortie des mises à jour, pour être sûr de ne pas zapper une mise à jour de sécurité, importante de fait. Dell et HP proposent tous deux leur service de « driver and support alerts » ou « Driver and Firmware Update notifications » :

    • Chez Dell, c'est accessible en bas de la page concernant un produit, comme celle que j'ai pointée ci-dessus.
    • Pour HP, il faut cliquer sur un driver/firmware depuis la page concernant un produit, genre iLO, puis descendre en bas de la page.
    Mon Jul 4 18:02:25 2016 - permalink -
    - http://shaarli.guiguishow.info/?bfiXRg
  • AdminRezoHP ILO sous Linux | AdminRezo

    Chez ARN, FAI associatif en Alsace, nos machines physiques ont une BMC c'est-à-dire un contrôleur permettant le management à distance (accès console, reboot, monitoring bas niveau,...) de la bécane (voir https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller). Super utile en cas de panne, fausse manip' qui évite de bouger au datacenter où elles sont hébergées.

    La BMC de notre HP ProLiant, un truc ILO 2 est perfectible : elle peut continuer à ping mais ne plus présenter son interface web... et devenir ainsi inutile. Le seul moyen est de rebooter totalement (éteindre + couper les arrivées électriques) la machine. Pas cool de découvrir ça quand on a besoin de la BMC car on a foiré une manip'...

    On a mis en place un check de monitoring (voir http://shaarli.guiguishow.info/?wehQjg ) supplémentaire qui vérifie, en plus d'un ping que l'interface web répond toujours. La question est : on ne va quand même pas rebooter intégralement la machine à chaque fois que le check remonte une erreur car, même si l'infra est redondée, ça fait une intervention humaine et on sait tous et toutes que le temps bénévole est rare. Pourtant, ne pas le faire, c'est s'exposer à un adminsys qui oublie que la BMC est HS avant de faire une manip' risquée ainsi qu'à une panne que la BMC permettrait de corriger.

    Quelles sont nos options ?
        * « impitool mc reset warn » n'est pas reconnue par la BMC, « reset cold » ne fonctionne pas ;

        * On peut utiliser la console accessible via SSH pour reboot uniquement la BMC (voir http://www.thevirtualway.it/2014/05/hp-ilo-how-to-reset-from-command-line/ ) mais vu qu'aucune communication réseau n'est possible au-delà de la couche 4, ça ne marchera pas ;

        * HP propose un outil « Standalone Remote Console » (voir http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=5228286&swLangOid=8&swEnvOid=4053 )... C'est du soft proprio disponible uniquement sous winwin et Red Hat ou en appli mobile (oui, LOL, je fais de la maintenance sérieuse avec mon ordiphone cracra mais bien sûr :- ) donc c'est mort de base. Ensuite, vu qu'aucune communication réseau avec la BMC n'est possible, c'est réglé.

        * Johndescs, qui a ses marques sur Dell/iDRAC, me dit qu'il y a un logiciel que tu mets sur le serveur lui-même et qui cause en local à la BMC du nom de racadm et qu'il doit bien y avoir un équivalent HP. Oui, ça existe, ça se nomme hponcfg (voir http://blog.adminrezo.fr/2015/09/hp-ilo-sous-linux/ ) et on peut rebooter seulement la BMC avec (voir http://community.hpe.com/t5/ProLiant-Servers-Netservers/Reboot-ILO-with-hponcfg/m-p/6413048#M20349 ).

            Le problème, c'est d'installer c'te truc. HP fournit un dépôt apt (ou yum ;) ) : http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/  mais hponcfg impose l'installation de hp-health qui fout des initscripts et plein de merdes. NO. FUCKING. WAY.

            On va extraire les binaires et les libs du package hponcfg :
                * wget http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/hponcfg_4.4.0.8-2._amd64.deb

                * dpkg -x hponcfg_4.4.0.8-2._amd64.deb hponcfg

                * sudo mv hponcfg/usr/sbin/hponcfg /usr/sbin/

                * sudo mv hponcfg/usr/lib/libhponcfg64.so /usr/lib/

                * En effectuant un strace, on remarque que le binaire tente de charger une lib libcpqci64.so et qu'il n'échoue pas s'il ne la trouve pas. En fait, elle est un doublon de libhponcfg64.so comme l'indique le message d'erreur de hponcfg quand on n'a aucun des deux libs : « Error Loading the library libcpqci.so or libhponcfg.so ». Si jamais ça peut servir : la libcpqci64.so est fournie avec hp-health.

                * On charge le module hpilo (fournit par Debian) dont le rôle est de faire la liaison avec la BMC en créant des fichiers /dev/hpilo/* dans lesquels il suffit de read() et write() pour communiquer avec la BMC : « sudo modprobe hpilo » .

            On exécute hponcfg : « sudo hponcfg » ... et là, c'est le drame :
                « ERROR: CpqCiCreateFunc() 0 time failed.
                  Driver Error Code:(1,1h).
                  Driver Error Message: CPQCIDRV driver is not loaded.

                  ERROR: A general system error occurred while detecting Management Processor.
                  ACTION REQUIRED: Check if iLO and iLO driver are up and running. »

                Vérifiez bien que vous avez chargé le module hpilo car les messages d'erreur entre "BMC viandée" et "absence du module hpilo" sont quasi identique, seul le message à la fin (« ERROR: [...] » change !

                Si vous regardez /var/log/kern.log, vous aurez quelques messages identiques à chaque essai de hponcfg : « [3890626.816095] hpilo 0000:01:04.2: Open could not dequeue a packet ».

                Si l'on regarde le code du module hpilo, on se rend compte que ça ne présage rien de bon : « * make sure iLO is really handling requests */ »

                On joue quand même le jeu : puisque hpilo crée des fichiers dans lesquels on peut lire et écrire pour causer à la BMC, faisons le :
                  $ echo "areUinlife?" | sudo tee /dev/hpilo/d0ccb15
                  Device or resource busy
                  lol
                Et on retrouve le même message dans kern.log...

                On pourrait vouloir utiliser d'autres outils userspace pour écrire dans les /dev/hpilo/* mais on se souvient alors que la communication avec la BMC est dans un langage propriétaire et que personne ne semble avoir souhaité passer son temps à reverse ça (et ce n'est pas un reproche). Même python-hpilo utilise une communication réseau ou parse hponcfg.

            Après un reboot électrique du HP, il est parfaitement possible d'écrire dans les /dev/hpilo/* et d'utiliser hponcfg :
              « sudo hponcfg -get_hostinfo
                HP Lights-Out Online Configuration utility
                Version 4.4.0 Date 06/13/2014 (c) Hewlett-Packard Company, 2014
                Firmware Revision = <censure> Device type = iLO 2 Driver name = hpilo
                Host Information:
                                     Server Name: <censure>
                                     Server Number: 000000000 »


    Qu'est-ce que tout cela signifie ? Que quand une BMC HP ILO est viandée, il n'y a pas d'autres moyens de la reboot que d'effectuer un reboot électrique complet de toute la machine ! C'est franchement super pratique... :'(

    ÉDIT DU 05/06/2017 À 16H10 :  en mettant à jour le firmware de la BMC à la dernière version disponible à ce jour (la 2,29 du 7 octobre 2015), l'interface web de la BMC ne se viande plus. Tuto pour la màj : http://shaarli.guiguishow.info/?bfiXRg . FIN DE L'ÉDIT.
    Wed Feb 3 02:51:18 2016 - permalink -
    - http://blog.adminrezo.fr/2015/09/hp-ilo-sous-linux/
    nomarkdown
  • Nagios: CRITICAL - Socket timeout after 10 seconds - Stack Overflow

    Chez ARN, FAI associatif en Alsace, nos machines ont une BMC c'est-à-dire un contrôleur permettant le management à distance (accès console, reboot, monitoring bas niveau,...) de la bécane (voir https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller).

    La BMC de notre HP, un truc ILO 2 est perfectible : elle peut continuer à ping mais ne plus présenter son interface web... et devenir ainsi inutile. Impossible de reboot uniquement la BMC depuis le serveur lui-même (ipmitool bmc reset cold, voir https://serverfault.com/questions/205658/restarting-an-ibm-bmc-without-restarting-the-server-itself) dans ces moments-là : ça ne juste fonctionne pas. Le seul moyen est de rebooter totalement (éteindre + couper les arrivées électriques) la machine. Pas cool de découvrir ça quand on a besoin de la BMC car on a foiré un truc...

    On a donc mis en place un monitoring HTTP en plus du monitoring ICMP des BMC. Aucun problème sur notre Dell iDRAC... Problème sur notre ILO 2, bien entendu : le check retourne toujours « CRITICAL - Socket timeout after 10 seconds » même si l'on augmente la durée avant timeout. Un navigateur web ne rencontre aucun problème. Problème avec TLS, peut-être ? Non, une capture réseau montre que c'est la même version de TLS et la même suite cryptographique qui sont choisis dans les deux cas (check et navigateur web).

    Ce n'est pas la faute de la BMC mais celle du check de monitoring check_http que l'on trouve dans nagios. En effet, ce dernier exécute une requête HTTP 1.1. La BMC répond avec un Content-Type: chunked. La norme HTTP 1.1 *impose* le support de ce content-type donc la BMC n'est pas fautive : le check demande à causer HTTP 1.1 sans savoir parler la langue... Depuis mi-2014 environ (voir https://github.com/monitoring-plugins/monitoring-plugins/pull/1286), check_http sait causer chunked mais visiblement, c'est sacrément buggué (voir https://github.com/nagios-plugins/nagios-plugins/issues/103 par exemple).

    Conclusion : on utilise l'argument « -N » de check_http pour lui dire de se concentrer sur les entêtes HTTP uniquement, et non pas sur le contenu envoyé par la BMC. Ainsi, on vérifie quand même que la BMC est fonctionnelle (une connexion HTTP est possible) sans se prendre la tête.
    Fri Jan 1 16:21:03 2016 - permalink -
    - https://stackoverflow.com/questions/7871009/nagios-critical-socket-timeout-after-10-seconds
    nomarkdown
  • #780407 - netfilter-persistent: boot continues if netfilter-persistent fails - Debian Bug report logs

    Je confirme :

    « sudo service netfilter-persistent restart
    A dependency job for netfilter-persistent.service failed. See 'journalctl -xn' for details.

    sudo journalctl -xn
    -- Logs begin at lun. 2015-11-02 13:24:33 CET, end at mar. 2015-11-03 12:20:31 CET. --
    nov. 03 12:20:13 porygon kernel: ipmi_si: Unable to find any System Interface(s)
    nov. 03 12:20:13 porygon systemd-modules-load[30688]: Failed to insert 'ipmi_si': No such device
    nov. 03 12:20:13 porygon systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
    nov. 03 12:20:13 porygon systemd[1]: Failed to start Load Kernel Modules.
    -- Subject: L'unité (unit) systemd-modules-load.service a échoué
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- L'unité (unit) systemd-modules-load.service a échoué, avec le résultat failed.
    nov. 03 12:20:13 porygon systemd[1]: Dependency failed for netfilter persistent configuration.
    -- Subject: L'unité (unit) netfilter-persistent.service a échoué
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- L'unité (unit) netfilter-persistent.service a échoué, avec le résultat dependency. »

    J'ai le package ipmitool installé pour accéder à des BMC de serveurs distants en cas de problème. Ce package fournit à la fois les outils clients mais aussi les outils "serveur" donc les modules pour que le noyau reconnaisse les BMC... Je n'ai pas de BMC sur mon laptop donc le chargement du module échoue. Donc systemd-module-load échoue et, par dépendance, n'active pas netfilter-persistent...

    Je trouve ce comportement extrêmement dangereux : il suffit qu'un seul module ne se charge pas et pouf plus de pare-feu. Comme le signale le bugreport, quand j'installe ipmitool (ou cups dans le cas rapporté dans le bugreport), je ne m'attends pas à perdre mon firewall.

    Workaround : blacklister le module ipmi_si dans /etc/modprobe.d/ mais ça ne résout pas le problème à la racine et ça peut péter à la gueule avec d'autres modules...

    Solution : lire l'excellent post de Michael Campbell dans le bugreport : on veut « Wants », pas « Requires ». Ainsi, si un module conntrack foire, netfilter-persistent foirera et c'est bien normal. Si un autre module foire, netfilter-persistent ne foirera pas. Logique. J'ai donc appliqué ce fix : sudo cp /lib/systemd/system/netfilter-persistent.service /etc/systemd/system/ + faire la modif Requires/Wants dans /etc/systemd/system/netfilter-persistent.service + sudo systemctl daemon-reload + sudo systemctl start netfilter-persistent.service

    Une autre solution serait que systemd-module-load soit un template. Ainsi, on aurait systemd-module-load@ipmi_si.service, systemd-module-load@uvcvideo.service,... Désactiver un module reviendrait à disable une unit. Solution parfaite pour systemd qui, par conception, veut tout remplacer dans notre système (init, syslog, fsck,...) : on remplacerait modprobe et sa blacklist. ;))))
    Tue Nov 3 23:16:19 2015 - permalink -
    - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780407
    nomarkdown
  • Dan Farmer Presents Research on IPMI Vulnerabilities | Threatpost | The first stop for security news

    « Short for Intelligent Platform Management Interface, these tiny computers live as an embedded Linux system attached to the motherboards of big servers from vendors such as IBM, Dell and HP. IPMI is used by a Baseboard Management Controller (BMC) to manage Out-of-Band communication, essentially giving admins remote control over servers and devices, including memory, networking capabilities and storage.

    [...]

    Yesterday, Farmer released a paper called “Sold Down the River,” in which he chastises big hardware vendors for ignoring security vulnerabilities and poor configurations that are trivial to find and exploit.

    [...]

    “Many of these problems would have been easy to fix if the IPMI protocol had undergone a serious security review or if the developers of modern BMCs had spent a little more effort in hardening their products and giving their customers the tools to secure their servers,” Farmer wrote.

    [...]

    Farmer said the number of servers with vulnerable BMCs have given IPMI insecurity a long shelf life. Moore’s scan pulled up 230,000 responses over port 623, an admittedly tiny slice of the overall number of implementations. Yet Farmer concludes that 90 percent of BMCs running IPMI could be compromised because of default or weak passwords or weaknesses in the protocol, not only implicating the host server but others in the same management group because, as he discovered, some vendors share common passwords.

    [...]

    There are two popular versions of IPMI, 1.5 and 2.0, and there is almost a 50-50 split in deployments. BMCs running version 1.5 are, however, seriously plagued by a vulnerability in that nearly all server management ports have NULL authentication set, allowing log-ins without authentication. Nearly all BMCs, Farmer said, also have NULL enabled, which, when combined with the server management issue, gives hackers an open door to any older IPMI system. “The privileges associated with the NULL account vary from vendor to vendor, but it seems to usually grant administrator access,” Farmer wrote.

    [...]

    Farmer said 90.1 percent of IPMI 1.5 systems had NULL authentication enabled. Compounding the issue is that 1.5 also lacks cryptographic protection between the user and BMC, leaving it vulnerable to attacks against network traffic such as password sniffing and man-in-the-middle attacks.

    {...]

    Version 2.0, meanwhile, includes some crypto protections and some vendors recognized NULL authentication as a vulnerability and fixed it in about half of the implementations. The crypto used, however, introduces new security issues, Farmer said. The Cipher Zero protocol allows an outsider to log in without authentication, only a valid user name; any password will be ignored, Farmer said. Most server vendors enable it by default on their BMC; HP recently gave users the option of turning it off for the first time, Farmer said.

    [...]

    Farmer said he used Metasploit to scan IPMI 2.0 BMCs to gather password hashes from 83 percent of those systems, and using the popular John The Ripper password cracker, he was able to get 30 percent of those passwords. And most of those passwords were easily guessable passwords such as “admin.”

    Further testing, Farmer said, revealed that 11,500 BMCs shared a common password, which could have been an undocumented default password; and another 1,300 BMCs, most in Europe on primarily on six networks, had a shared password, likely indicating a service provider using a common password to manage dispersed systems, Farmer said. »
    Sun Jun 8 21:13:27 2014 - permalink -
    - http://threatpost.com/vulnerabilities-in-ipmi-protocol-have-long-shelf-life/106480
    nomarkdown
Links per page: 20 50 100
page 1 / 1
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community