Oggi ho passato delle ore a risolvere un rewrite globale in apache tramite htaccess. In pratica avevo bisogno di reindirizzare tutte le richieste (anche a percorsi esistenti) ad un unico /index.php per evitare di copiare il bootstrap in ogni singolo file. Se visitavo /api/v1/list.php funzionava, ma con /api/v1/list senza estensione no. Perché??

Poi nel virtual host ho notato un'opzione curiosa: MultiViews. Se attiva, il modulo negotiations gestisce automaticamente la casistica di rewrite list > list.* bypassando il rewrite personalizzato...

In più le regole di rewrite possono essere ricorsive e se non si hanno altri modi vanno interrotte con il flag END

<IfModule mod_negotiation.c>
    Options -MultiViews
</IfModule>

DirectoryIndex index.php

RewriteEngine on
RewriteBase /project/

# passthrough
RewriteCond "%{REQUEST_URI}" "^\/project\/(static|res)"
RewriteRule . - [NC,QSA,L,END]

# all other requests to index.php,
# then access with $_SERVER['REQUEST_URI']
# RewriteCond "%{REQUEST_FILEPATH}" !-f
# RewriteCond "%{REQUEST_FILEPATH}" !-d
RewriteRule ^(.*)$ index.php [NC,QSA,L,END]

Ieri notte sono riuscito a collegare questo vecchio router moddato in modalità USB tethering — è decisamente buggato.

Appena avviato è in modalità router, ha una LAN propria con NAT verso la rete esterna. Tuttavia ha due problemi: come scritto sopra non sa come attivare il tethering, in più è deciso a non far partire il server DHCP.

Dopo aver attivato il tethering ho provato a disattivare e riattivare l'impostazione DHCP, ma facendo così ecco che entra in modalità bridge (layer 2) + IP (simile ad un access point). I dispositivi comunicano direttamente con la rete esterna e c'è internet, infatti ottengono un IP di quella rete, però l'unico modo che hanno per raggiungere questo router è impostare un indirizzo fisso di quella subnet.

Sempre in questa modalità di bridge il router anche avendo un IP "perde" l'accesso alla scheda di rete USB, infatti non raggiunge alcun dispositivo. Si potrebbe chiamarlo un "bridge ad occhi chiusi".

Riavvio il dispositivo da interfaccia web, torna in modalità router senza DHCP ma il tethering USB rimane magicamente attivo. Come faccio quindi a risolvere quest'ultimo punto?

Sempre da interfaccia, vedo che è possibile utilizzare dnsmasq con configurazione personalizzata per DNS + DHCP server. Provo ad attivarlo e dopo un po' di tentativi, ecco che funziona tutto.

I dispositivi connessi a questo router prendono automaticamente un IP della sua LAN, si vedono tra di loro, raggiungono internet e pure la saponetta.

Quindi, quando accendo fisicamente il router, ora devo solo attivare il tethering:
1. connettermi al wifi (dnsmasq è già attivo)
2. connettermi in telnet
3. mount -t usbfs usbfs /proc/bus/usb
4. usb_modeswitch -v 1bbb -p f000 -c /config/xxx/device.conf

E nel caso dnsmasq non sia in esecuzione:
5. pkill dnrd_1
6. dnsmasq -C /config/xxx/amod/dnsmasq/dnsmasq.conf

Arrivata la zimaboard, a casa la spacchetto

Sembra di star spacchettando il Nintendo DS Lite, le vibes sono le stesse — che throwback...

Ottima privacy policy: 4 pagine,

NON collezioniamo, salviamo, usiamo, analizziamo alcun dato personale

Prima di configurare tutto devo cercare di centralizzare gli account (keycloak? freeipa? ldap? oauth?), non mi va di far registrare a tutti un proprio account su ogni servizio

Ovviamente la capacità o meno di integrarsi con questo tipo di autorizzazioni dipenderà dai singoli servizi

Mi segnalano
https://ssotax.org/

Mi chiedo con quali fotocamere scattino queste immagini...
https://t.me/ilfattoalimentareallerta/1038?single

Volevo aggiungere un minuscolo servizio di my-ip attraverso caddy, ma scopro che docker rootless con i driver di default maschera l'IP sorgente oltre che ad essere decisamente lento.

Ora provo ad installare bypass4netns che dovrebbe risolvere tutto con regole seccomp.

Gli user namespace sembrano essere visti come pessimi per la sicurezza, non sapevo... Non sono ancora riuscito a far funzionare la connettività nei container, a questo punto ritorno a docker rootful (con l'unica eccezione di usare passwd + group custom)

(post del 2019 ma ancora aggiornato)

Enabling unprivileged user namespaces can make severe vulnerabilities in the Linux kernel much more easily exploitable. [...] Numerous vulnerabilities that are found regularly are often only exploitable by unprivileged users [...]

The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.

https://security.stackexchange.com/questions/267628/user-namespaces-do-they-increase-security-or-introduce-new-attack-surface

https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3DR5w

E niente come non detto, ho scritto a mano tutte le regole del firewall in bash

Funziona sia pre- che post-esecuzione docker

L'altro giorno faccio per accendere la zimaboard con un HDD SATA, un tastiera e un adattatore mini DisplayPort / HDMI ...non si accende.

Preoccupato, scollego l'adattatore video e l'HDD pensando che richiedano troppa corrente ...niente.

Smonto tutto, apro la board, scollego ventola e batteria CMOS e si rovina il connettore esterno di quest'ultima. Rinforzo il connettore scollegato con una goccia di colla a caldo e faccio uguale con quello della ventola, tutto ok.

Per curiosità raggiungo l'altro lato della board e scopro che la pasta termica è come sempre scadente. Pulisco tutto con alcol e ne metto di nuova.

Chiudo tutto, collego l'alimentatore ...si accende. Riprovo a collegare i dispositivi da spenta ...rimane spenta.

Ho descritto la situazione sul server discord ufficiale e uno mi ha suggerito di provare a collegare i dispositivi da board accesa, e funzionano tutti insieme. Vai a capire...

Comunque ho letto che in caso di board arrivata danneggiata, in teoria l'azienda può provvedere ad inviarne una nuova

Per quanto riguarda ZimaOS, sempre ieri sera mi sono rivisto dei video di MorroLinux sull'argomento che confermano i miei presentimenti.

È una distribuzione embedded custom fatta con Buildroot, la root è in sola lettura, non ha package manager e si aggiorna con un singolo file che viene installato su una seconda partizione (sistema A/B come android (e steamdeck?)).

Questo perché è pensata per utenti interessati agli argomenti NAS / homelab / privacy / data sovereignty, ma comunque poco tecnici o avversi a configurazioni manuali (come biasimarli).

Peccato che delle funzioni che vende, raggiunge poco; il sistema sembra in costante alpha —
• puoi configurare i permessi delle condivisioni samba ma funziona solo guest pubblico (non aggiunge gli utenti con smbpasswd),
• i parametri di rete sono modificabili solo in parte, per extra bisogna usare NetworkManager,
• non avvisa se un disco del RAID sta fallendo
• e come mi era successo in passato sul mio pc, se si attiva lo sleep automatico dell'HDD poi viene riacceso dai controlli SMART periodici (disattivabili solo da ssh).

Infine c'è una funzionalità opzionale per connettersi alla rete della board da internet tramite il loro ZimaClient, che esiste per Windows, macOS, Android ...ma non linux. Tale funzionalità più il client non sono altro che un rebrand di ZeroTierOne (possono farlo? non è FOSS per usi commerciali).

Detto questo, mi sa che farò un backup del sistema e installerò Arch

Ecco i risultati dei test (povera board l'ho torturata a forza di accendi-spegni...)
• spenta da web e scollegato tutto

• solo power
accesa, ma al secondo tentativo

• power + miniDP adapter (senza monitor)
accesa

• power + miniDP w/o mon + usb keyboard
accesa

• power + miniDP w/o mon + usb keyboard
+ usb flash
accesa

• power + miniDP w/ monitor
niente

• power + sata solo dati
accesa

• power + sata
accesa, ma al secondo tentativo

• power + sata + miniDP w/o mon + usb keyboard
+ usb flash
accesa