Archivi autore: angelo_admin

Aggiornare BIOS by Linux

E’ sempre stato Winzoz che ha avuto la meglio sul pinguino, ma sembra che finalmente le cose si stiano muovendo bene ed in questo caso la rete aiuta.

Volevo fare l’aggiornamento del mio Lenovo, ma sul sito era presente solo il soft che girava sotto Win, ma dopo una breve ricerca ho trovato il modo:

LVFS aka Linux Vendor Firmare Service (attivo per alcuni marchi dal 2015)

Ebbene i passi sono molto pochi e semplici

Installare fwupd con il solito

sudo apt install fwupd

e far partire il servizio

sudo systemctl start fwupd

fare il refresh dei firmware disponibili con

sudo fwupdmgr refresh

ottenere la lista dei dispositivi disponibili con

fwupdmgr get-devices

ottenere la lista dei dispositivi aggiornabili

fwupdmgr get-updates

ed aggiornare con

fwupdmgr update

Qui serve la solita connessione ad Internet in quanto i pacchetti vengono recuperati direttamente sulla rete

Se l’aggiornamento interessa il BIOS del pc, saranno necessari alcuni minuti e diversi reboot, ma alla fine tutto va liscio !

OwnCloud su Ubuntu: nginx e postgresql

Volevo giocare con owncloud, ma non volevo la solita accoppiata mysql e apache2, ma nginx e postgresql.

Tuttavia ho dovuto mettere le mani nei file di configurazione della macchina:

owncloud non accetta versioni di php maggiori di 7, ma ubuntu 22.04 non ha più il supporto per la 7.4, ma solo la 8.1.

Ho aggiunto un repository con

sudo add-apt-repository ppa:ondrej/php -y

e poi

sudo apt-get update 
sudo apt-get install nginx 

seguito da un

sudo apt-get install php7.4 php7.4-fpm
sudo apt-get install php7.4-json \
php7.4-curl  php7.4-imap php7.4-mcrypt   \
php7.4-mcrypt php7.4-xmlrpc php7.4-zip   \
php7.4-zip  php7.4-pgsql  php7.4-opcache \
php7.4-cli php7.4-gmp php7.0-gd \
php7.4-xml  php7.4-ldap php7.4-intl php7.4-mbstring

dal sito di owncloud ho prese l’ultima versione disponibile con

wget https://download.owncloud.com/server/stable/owncloud-complete-latest.zip

quindi ho spacchetta il tutto sotto /var/www, chmlod per cambiare l’utente da root in www-data, ho aggiunto il file della configurazione del server sotto /etc/nginx/site-available

upstream php-handler {
  server unix:/run/php/php7.4-fpm.sock;
}

server {
  listen 80;
  server_name owncloud.example.com;
  # enforce https
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name owncloud.example.com;

  ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
  ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

  # Add headers to serve security related headers
  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Robots-Tag none;
  add_header X-Download-Options noopen;
  add_header X-Permitted-Cross-Domain-Policies none;

  # Path to the root of your installation
  root /var/www/owncloud/;
  # set max upload size
  client_max_body_size 10G;
  fastcgi_buffers 64 4K;

  # Disable gzip to avoid the removal of the ETag header
  gzip off;

  # Uncomment if your server is build with the ngx_pagespeed module
  # This module is currently not supported.
  #pagespeed off;

  index index.php;
  error_page 403 /core/templates/403.php;
  error_page 404 /core/templates/404.php;

  rewrite ^/.well-known/carddav /remote.php/dav/ permanent;
  rewrite ^/.well-known/caldav /remote.php/dav/ permanent;

  # The following 2 rules are only needed for the user_webfinger app.
  # Uncomment it if you're planning to use this app.
  #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
  #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

  location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
  }

  location ~ ^/(build|tests|config|lib|3rdparty|templates|data)/ {
    deny all;
  }

  location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
    deny all;
  }

  location / {

    rewrite ^/remote/(.*) /remote.php last;

    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

    try_files $uri $uri/ =404;
  }

  location ~ \.php(?:$|/) {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param HTTPS on;
    fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
    fastcgi_pass php-handler;
    fastcgi_intercept_errors on;
  }

  # Adding the cache control header for js and css files
  # Make sure it is BELOW the location ~ \.php(?:$|/) { block
  location ~* \.(?:css|js)$ {
    add_header Cache-Control "public, max-age=7200";
    # Add headers to serve security related headers
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    # Optional: Don't log access to assets
    access_log off;
  }

  # Optional: Don't log access to other assets
  location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|swf)$ {
    access_log off;
  }
}

Ho creato i certificati selfsigned con

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

sulla macchina che utilizzo come database ho creato quanto serve a owncloud

sudo su postgres

# Then lets setup `role` and create database for owncloud 
postgres@userver:/home/alok$ psql 

postgres=# CREATE ROLE owncloud ; 
postgres=# ALTER ROLE owncloud WITH PASSWORD 'myPassword' ;
postgres=# ALTER ROLE owncloud WITH LOGIN ;

postgres=# CREATE DATABASE owncloud ;
postgres=# ALTER DATABASE owncloud OWNER TO owncloud ;

postgres=# \list
postgres=# \q 

e digitando

https://owncloud.example.com (nome di fantasia)

appare la schermata per la configurazione di base di owncloud !!

La lista della spesa di Proxmox

Ieri mi è stata fatta la richiesta di avere la lista di tutte le macchine visrtuali per una loro eventuale migrazione.

Mi è preso un colpo ! Stavo già pensando a riempire un foglio in Libreoffice passando giornate a verificare la correttezza dei dati.. ma poi con un

pvesh get /cluster/resources --output-format text

mi sono trovato in un bellissimo foglio di banale testo la lista delle macchine, ma senza l’ip.

│ qemu/100 │ qemu    │   │  2.56% │ 0.00 B   │  │  │  4 │  240.00 GiB │   2.00 GiB │ 1.40 GiB   │
(per motivi di impaginazione ho ridotto gli spazi)

Questo viene recuperato, se il qemu-agent è installato sulla macchine, con un

pvesh get /nodes/pve/$line/agent/network-get-interfaces -o json-pretty

dove la variabile $line e il nome della macchina del precedente output e pve è il nome della macchina.

In definitiva le mia macchina qemu/100, deve essere indicate con anche nome del server sul quale insiste tipo

pve/qemu/100

Quick and dirty : aws tag reserved instances

aws ec2 describe-reserved-instances
{
    "ReservedInstances": [
        {
            "Duration": 57024000,
            "End": "2026-02-12T16:11:46+00:00",
            "FixedPrice": 0.0,
            "InstanceCount": 3,
            "InstanceType": "r5a.xlarge",
            "ProductDescription": "Linux/UNIX",
            "ReservedInstancesId": "c5851026-2b6f-4d5c-99ba-946146221ac0",
            "Start": "2024-04-23T16:11:47.169000+00:00",
            "State": "active",
            "UsagePrice": 0.0,
            "CurrencyCode": "USD",
            "InstanceTenancy": "default",
            "OfferingClass": "standard",
            "OfferingType": "No Upfront",
            "RecurringCharges": [
                {
                    "Amount": 0.099,
                    "Frequency": "Hourly"
                }
            ],
            "Scope": "Region"
        }
    ]
}

aws ec2 create-tags --resources c5851026-2b6f-4d5c-99ba-946146221ac0 --tags Key=project,Value=200029

aws ec2 describe-reserved-instances                                                                 
{
    "ReservedInstances": [
        {
            "Duration": 57024000,
            "End": "2026-02-12T16:11:46+00:00",
            "FixedPrice": 0.0,
            "InstanceCount": 3,
            "InstanceType": "r5a.xlarge",
            "ProductDescription": "Linux/UNIX",
            "ReservedInstancesId": "c5851026-2b6f-4d5c-99ba-946146221ac0",
            "Start": "2024-04-23T16:11:47.169000+00:00",
            "State": "active",
            "UsagePrice": 0.0,
            "CurrencyCode": "USD",
            "InstanceTenancy": "default",
            "OfferingClass": "standard",
            "OfferingType": "No Upfront",
            "RecurringCharges": [
                {
                    "Amount": 0.099,
                    "Frequency": "Hourly"
                }
            ],
            "Scope": "Region",
            "Tags": [
                {
                    "Key": "project",
                    "Value": "200029"
                }
            ]
        }
    ]
}

Magari esisterà anche un altro modo, ma questo ha funzionato subito taggando le risorse

Piwigo e docker

Sto per cambiare radicalmente la configurazione della mia infrastruttura e la cosa che mi interessava era quella di poter ancora depositare su qualche parte le foto del rugby / harpastum che realizzo per i figli e, siccome l’appetito vien mangiando e non volendo installare effettivamente i pacchetti ho pensato di vedere se e come con docker si potesse fare.

Ho seguito le indicazioni in rete ed ho generato il seguente docker-composer.yml


services:
mysql-server-80:
image: mysql/mysql-server:8.0
volumes:
- /home/dockeruser/docker-piwigo/mysql/:/var/lib/mysql/
ports:
- "3306:3306"
restart: always
environment:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: piwigo
MYSQL_USER: utente
MYSQL_PASSWORD: password
piwigo:
image: lscr.io/linuxserver/piwigo:latest
container_name: piwigo
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Rome
volumes:
- /home/dockeruser/docker-piwigo/config:/config
- /home/dockeruser/docker-piwigo/gallery:/gallery
ports:
- 80:80
restart: unless-stopped
depends_on:
- mysql-server-80

La parte complicata è stata l’individuazione del nome della macchina che esponeva il servizio di mysql: all’inzio pensavo che fosse mysql-server-80, ma mi sono ricreduto quyando ho visto i nomi dei conainer presenti sulla rete di pwigo

docker network ls

riporta

274d82b58ef7 docker-piwigo_default bridge local

e poi con

docker network inspect docker-piwigo_default

ho avuto la conferma che il nome non era quello:

[
    {
        "Name": "docker-piwigo_default",
        "Id": "274d82b58ef7a0c0ab416ea16a7a81e58f083748aef29e0b7bfff324c62f05ea",
        "Created": "2024-04-21T09:59:37.303645746Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.21.0.0/16",
                    "Gateway": "172.21.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "4d3af57c45055f7f887de168d8b894a87345bc2584f77e90c5b986baf8fbd12b": {
                "Name": "docker-piwigo_mysql-server-80_1",
                "EndpointID": "fd26e447aa94e9188f9661c13420ef4edfd45c2f0d4c3c6ae2137f63ae68e540",
                "MacAddress": "02:42:ac:15:00:02",
                "IPv4Address": "172.21.0.2/16",
                "IPv6Address": ""
            },
            "8b08f8b67ff6b513627a9432ad6f81c222bff572460a0cd011e39b4b7d79304c": {
                "Name": "piwigo",
                "EndpointID": "9f7a1699f512bf9a784378a5fdd954c80aef488e1162cb2f14f611ed3a6d57ab",
                "MacAddress": "02:42:ac:15:00:03",
                "IPv4Address": "172.21.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "docker-piwigo",
            "com.docker.compose.version": "1.29.2"
        }
    }
]

ed impostando nel nome del server del db docker-piwigo_mysql-server-80_1 della configurazione di piwigo sono riuscito ad andare avanti,

ma mancava nella definizione del db l’utente e password. Mi sono cellagato sul docker del db con

docker exec -it docker-piwigo_mysql-server-80_1 /bin/bash
bash-4.4# mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 8.0.32 MySQL Community Server - GPL

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE USER 'utente'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.02 sec)

mysql> GRANT all PRIVILEGES ON piwigo.* TO 'utente'@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye

A questo punto la configurazione è andata a buon fine e il docker con piwigo e mysql funziona perfettamente

Aggiornamento pfSense 22.05

Per condividere un problema verificato su pfSense 22.05 con la scritta laconica

Unable to check for updates

quando, sulla home oage, provavi a verificare la presenza o meno di aggiornamenti.

il problema risiede nel file di configurazione errato:

more /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf
FreeBSD: { enabled: no }

pfSense-core: {
url: “/pfSense_plus-v22_05_amd64-core”,
mirror_type: “srv”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/share/pfSense/keys/pkg”,
enabled: yes
}

pfSense: {
url: “/pfSense_plus-v22_05_amd64-pfSense_plus_v22_05”,
mirror_type: “srv”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/share/pfSense/keys/pkg”,
enabled: yes
}

il file di configurazione corretto punta ad un url diversa:

more /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf

FreeBSD: { enabled: no }

pfSense-core: {
url: “pkg+https://firmware.netgate.com/pkg/pfSense_plus-v22_05_amd64-core”,
mirror_type: “srv”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/share/pfSense/keys/pkg”,
enabled: yes
}

pfSense: {
url: “pkg+https://firmware.netgate.com/pkg/pfSense_plus-v22_05_amd64-pfSense_plus_v22_05”,
url: “/pfSense_plus-v22_05_amd64-pfSense_plus_v22_05”,
mirror_type: “srv”,
signature_type: “fingerprints”,
fingerprints: “/usr/local/share/pfSense/keys/pkg”,
enabled: yes
}

appare finalmente

Version 23.01 is available.

Version information updated at Mon Mar 25 13:19:59 CET 2024  

Mongo reindex

Quando faccio la copia dei date da un db ad un altro e devo ricreare gli indici

db.getCollectionNames().forEach(function(col) {
    var indexes = db[col].getIndexes();
    indexes.forEach(function (c) {
        var fields = '', result = '', options = {};
        for (var i in c) {
            if (i == 'key') {
                fields = c[i];
            } else if (i == 'name' && c[i] == '_id_') {
                return;
            } else if (i != 'name' && i != 'v' && i != 'ns') {
                options[i] = c[i];
            }
        }
        var fields = JSON.stringify(fields);
        var options = JSON.stringify(options);
        if (options == '{}') {
            result = "db." + col + ".createIndex(" + fields + "); ";
        } else {
            result = "db." + col + ".createIndex(" + fields + ", " + options + "); ";
        }
        result = result
            .replace(/{"floatApprox":-1,"top":-1,"bottom":-1}/ig, '-1')
            .replace(/{"floatApprox":(-?\d+)}/ig, '$1')
            .replace(/\{"\$numberLong":"(-?\d+)"\}/ig, '$1');
        print(result);
    });
});

con questo ottengo la lista degli indici dal DB di origine e poi l’output è la stringa che devo dare in pasto a Mongo per rigenerare l’indice, per esempio

db.collection.createIndex({"clientCode":1});

Postgresql e la funzione vacuum

Facendo l’aggiornamento di release di postgresql dalla 13.9 alla 15.2, in ambiente AWS,bisogna rifare le statistiche delle tabelle: ho cercato in giro se fosse possibile in maniera automatica, ma alla fine ho realizzato uno script per aggiornare le info:

schemas=psql -t -A -U USER -h IP_ADD DATABASE -c "select schema_name from information_schema.schemata"

for schema in $schemas
do
psql -t -A -U USER -h IP_ADD DATABASE -c "select format('analyse verbose %I.%I;', n.nspname::varchar, t.relname::varchar) FROM pg_class t JOIN pg_namespace n ON n.oid = t.relnamespace WHERE t.relkind = 'r' and n.nspname::varchar = '$schema' order by 1" | psql -U USER -h IP_ADD DATABASE
done

Come aggiungere spazio ad un disco di una VM sotto PVE

Di seguito quello che ho fatto per ampliare da 32 a 64GB lo spazio della mia macchina repository di immagini docker

[23059.572021] sd 2:0:0:0: [sda] 134217728 512-byte logical blocks: (68.7 GB/64.0 GiB)
[23059.573015] sda: detected capacity change from 67108864 to 134217728

root@docker:~# parted /dev/sda
GNU Parted 3.4
Using /dev/sda
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) print
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 67108864
blocks) or continue with the current setting?
Fix/Ignore? f
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 34.4GB 34.4GB ext4

(parted) resizepart 2 100%
Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?
Yes/No? y
(parted) print
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 68.7GB 68.7GB ext4

(parted) quit
Information: You may need to update /etc/fstab.

root@docker:~# resize2fs /dev/sda2
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 8
The filesystem on /dev/sda2 is now 16776699 (4k) blocks long.

root@docker:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 198M 1.3M 197M 1% /run
/dev/sda2 63G 28G 33G 47% /
tmpfs 988M 0 988M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 198M 4.0K 198M 1% /run/user/1000
overlay 63G 28G 33G 47% /var/lib/docker/overlay2/c3e70e17d7f859993c39376e66c91ac89099a1336d6bd5a577c701d3f687c921/merged
shm 64M 0 64M 0% /var/lib/docker/containers/677cfe3fd4c993f9a9f0ad650370d105bcc4c3c0e2ee46d012835b0348fdde31/mounts/shm

Accesso all’utente root di mysql da utente di sistema

Se provando a collegarti a mysql utilizzando:

mysql -u root -p

si ttiene questo errore, anche se la password è corretta,

ERROR 1698 (28000): Access denied for user 'root'@'localhost'

La soluzione è cambiare l’autorizzazione di Mysql per l’utente root da auth_socket a qualcos’altro come caching_sha2_password.

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'my_password'

Add a comment