Installer OpenWRT sur une borne unifi

Les bornes unifi sont des super produits pour les pros. Mais pour ceux qui en veulent toujours plus et se retrouvent limité par le système (sic…) il est possible d’aller encore plus loin. En effet, ces bornes sont toutes basés sur une version du système d’exploitation OpenWRT. Donc forcément compatible avec le système.

Bon, en vrai, la LED je la désactive

On a la confirmation en se connectant en ssh à la borne.


cat /etc/openwrt_release
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='17.01.6'
DISTRIB_REVISION='r3979-2252731af4'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='ar71xx/ubnt'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='LEDE Reboot 17.01.6 r3979-2252731af4'
DISTRIB_TAINTS='no-all mklibs busybox'
UnifiAP-AC-LR-BZ.v4.0.80# cat /etc/openwrt_version
r3979-2252731af4

Jusqu’à il y a peu, il était possible d’installer des paquets supplémentaires via opkg… Mais voilà, depuis, ubiquiti l’a interdit 🙁

Mais on peut installer OpenWRT, en perdant par contre la partie « gestion » via le logiciel unifi controller. A vous de voir ce qui vous intéresse.

Dans le cas ou vous souhaitez installer OpenWRT, c’est possible via le tutorial suivant :

https://openwrt.org/toh/ubiquiti/unifiac

ATTENTION pour le package mtd, j’ai du utilisé celui-ci https://downloads.openwrt.org/releases/17.01.6/packages/mips_24kc/base/mtd_23_mips_24kc.ipk

Pour l’installation, j’ai du le décompresser via 7-Zip sur mon poste de travail et j’ai du ensuite recopier l’exécutable dans le dossier /sbin de la borne.

Ensuite : redémarrage, et tout fonctionne du premier coup.

L’inconvénient, c’est que si on a plusieurs routeurs, ou plusieurs bornes, on risque de se retrouver en réseau local avec plusieurs DHCP (bof) et plusieurs DNS (rebof)

Heureusement, on peut facilement configurer les routeurs OpenWRT en mode « Dump AP » (Ce qu’on peut traduire par « point d’accès déversoir »…)

https://openwrt.org/docs/guide-user/network/wifi/dumbap

Zou, je retourne à ma configuration 🙂

Best method ever from Saturday Night

Connaître le niveau de batterie d’un appareil android sur jeedom

L’article suivant décrit le process permettant la mise en place d’un script ssh sous Jeedom;

Tutorial niveau et status batterie sous jeedom

Les adaptations nécessaires et les limitations :

  1. Si le téléphone ou la tablette est hors ligne, cela affiche un avertissement.
  2. Il faut fixer l’adresse IP de la tablette ou du smartphone
  3. Sur les versions récentes d’android, on ne peut pas afficher directement le status en charge / décharge ; Il faut utiliser un contournement suivant pour avoir l’info « Charging » / « Discharging » puis l’afficher via un widget. (voir le code ci-joint et la capture décran)
  4. Toujours sur les versions récentes d’android, l’application SSH doit être lancé ET visible en arrière plan, sinon ça ne marche pas. Si on oublie, pas d’info.
ssh -p 2222 <adresse IP> cat /sys/class/power_supply/battery/uevent | grep STATUS  | cut -d'=' -f2

Monitorer XTeVe via monit

XteVe est un « proxy » vers des serveurs IPTV via des listes M3U. Je l’utilise avec mon FAI (Free) pour interfacer les chaînes multipostes avec plex. On peut également l’utiliser pour regrouper des multiples playlist d’IPTV gratuites (par exemple : https://github.com/iptv-org/iptv)

Consulter le site officiel pour plus d’informations : https://xteve.de/

Oui mais voilà, parfois lors de l’enregistrement, XteVe plante (grrr…). Donc, j’ai souhaité rapidement ajouter un monitoring automatique à xteve pour permettre de le relancer sans intervention manuelle.

La première étape consiste à « transformer » xteve en démon. Ensuite, il faut utiliser un logiciel de monitoring type monit pour le surveiller. C’est simple donc 🙂

Création d’un démon de service

Créer le fichier de service :

cd /etc/systemd/system/
sudo vi xteve.service

Copier le contenu suivant

[Unit]
Description=xTeVe Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/dossier_installation/xteve -config dossier_configuration
ExecReload=/usr/bin/killall xteve
ExecStop=/usr/bin/killall xteve
KillMode=process
Restart=always
RestartSec=15

User=running_user
Group=running_group
[Install]
WantedBy=multi-user.target

Attention à bien remplir les éléments manquants : dossier_installation,dossier_configuration, running_user et running_group.

On sauvegarde le fichier, puis on active le nouveau service :

sudo systemctl enable xteve
sudo systemctl start xteve

Création du fichier de monitoring pour monit

On crée un nouveau fichier pour ce monitoring ;

sudo vi /etc/monit/conf.d/xteve
check process xteve matching "xteve"
    start program = "systemctl start xteve"
    stop program = "systemctl stop xteve"
    if failed host 127.0.0.1 port 33400 with timeout 30 seconds for 3 cycles then restart

Attention à adapter le numéro de port du monitoring.

Ensuite, il ne reste plus qu’à relancer monit :

sudo /etc/init.d/monit restart

Et voilà, xteve fonctionne désormais tout seul.

… Et les mises à jour ?

Ah… oui… le défaut, c’est que xteve se met à jour uniquement au démarrage de l’application.

Donc, il faut également penser à le relancer de temps à autre pour qu’il puisse faire ces mises à jour. Pour cela, le plus simple reste à rajouter une ligne dans le crontab pour le redémarrer par exemple une fois par semaine le mardi vers 4h du matin (peu de chances d’enregistrer quelque chose…)

Ce qui donne dans crontab :

0 4 * * 1 systemctl restart xteve