Unlock Keepass database with Gnome session unlock

In order to unlock your KeepassXC database when you unlock your session, do the following :

prerequisites :
install the packet libsecret-tools

1. put the password in the Gnome keyring
secret-tool store --label="KeePass" database <database_name>

2. create the script like this :
#!/bin/bash
secret-tool lookup database <database_name> | /usr/bin/keepassxc --pw-stdin <database_location> --keyfile <database_key_location>


3. Add a launcher at ~/.config/autostart/Keepass.desktop:
[Desktop Entry]
Name=Keepass Unlock
GenericName=KeepassUnlock
Comment=Unlocks the keepass DB at session unlock
Exec=<absolute_path_of_script>
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true

EDIT : added the use of a keyfile

Strongswan routed FQDN IPSec Ikev2 with certificates auth with a Fortigate

EDIT : I've updated with this tutorial from Google, with the updown script on strongswan:

https://cloud.google.com/community/tutorials/using-cloud-vpn-with-strongswan

The VPN is between :
- localsite.domain.com
    debian buster with strongswan 5.7.2-1
- remotesite.domain.com
    Fortigate 6.2.3

Important :

This will not work if the Kernel does not have the CONFIG_NET_IPVTI module enabled.
On OVH you have to upgrade to debian Buster that has a Kernel 4.19 (as of today)

create a PKI :

CA.crt
local.crt
local.pem
remote.crt

Configure IPSEC :

ipsec.conf

 config setup
        #charondebug="ike 3, net 2, esp 2, chd 2, pts 3, cfg 0, asn 0"
        uniqueids=yes
        strictcrlpolicy=no

conn %default
        # keyexchange=ikev2 # now ikev2 is default
        forceencaps=yes
        ike=aes256-sha256-modp2048!
        ikelifetime=24h
        # lifetime=43200s # default is 1h
        esp=aes256-sha256-modp2048,aes256gcm128-sha256
        leftauth=pubkey
        rightauth=pubkey
        closeaction=restart

conn homesite
        #here
        left=localsite.domain.com  
        # left|rightcert in /etc/ipsec.d/certs
        leftcert=local.crt
        # left|rightca in /etc/ipsec.d/cacerts
        leftca=CA.crt

leftsubnet=0.0.0.0/0

#remote
right=remote.domain.com
rightid="<remote site certificate DN>" # TODO check if it can be taken from cert

rightcert=remote.crt
rightca=%same
rightsubnet=0.0.0.0/0

auto=route
mark = 42

/etc/ipsec.secrets 

# cert has to be in /etc/ipsec.d/private/
: RSA local.pem

trust the CA

 cp CA.crt /etc/ipsec.d/cacerts/CA.crt

check that the certificates are recognized with 'ipsec listcerts'.

The flag 'has private key' needs to be present for the certificates with a private key provided.

modify apparmor charon to install DNS provided by tunnel

 I had an issue with apparmor that was not able to accept the dns settings, as the resolv.conf could not be modified in the charon apparmor module, so add at the bottom of the list, before the } in /etc/apparmor.d/usr.lib.ipsec.charon :

/etc/resolv.conf          rwk,

modify the /etc/hosts to resolve to your external IP

1.2.3.4    cloud.domain.com

Configure Route-based VPN :

In my case the local has a static IP. Otherwise, you have to use a script.

/etc/network/interfaces.d/ipsec0.conf

auto ipsec0
iface ipsec0 inet manual
        pre-up ip tunnel add ipsec0 local <ip of the localsite> remote 0.0.0.0 mode vti key 42
        up ip link set ipsec0 up
        up ip address add 10.2.0.2/24 dev ipsec0
        up ip route add 192.168.1.0/24 dev ipsec0 via 10.2.0.1
        up sysctl -w "net.ipv4.conf.ipsec0.disable_policy=1"

        down ip route del 192.168.0.0./24 dev ipsec0
        down ip address del 10.2.0.2/24 dev ipsec0
        post-down ip tunnel del ipsec0

/etc/strongswan.d/charon.conf :

install_routes = no
install_virtual_ip = no

Fortigate config 

Key exchange :

config vpn ipsec phase1-interface
    edit "VPNikev2"
        set type ddns
        set interface "wan1"
        set ike-version 2
        set authmethod signature
        set net-device disable
        set proposal aes256-sha256
        set remotegw-ddns "localsite.domain.com"
        set certificate "remote.crt"
        set peer "remote_side"
    next
end

ChildSA :

config vpn ipsec phase2-interface
    edit "VPNikev2p2"
        set phase1name "VPNikev2"
        set proposal aes256-sha256 aes256gcm
        set keylifeseconds 3600
    next
end

User config:

config user peer
    edit "remote_side"
        set ca "Root_CA"
        set subject "<DN to match localsite cert>"
    next
end

static route for RPF check:

config router static
     edit 0
         set dst 10.2.0.0 255.255.255.0
         set device "VPNikev2"
     next
end

change the container runtime in Kubernetes after upgrade to 1.21

 from https://v1-21.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/

 

find the cgroupDriver on the master node, then in /var/lib/kubelet/config.yaml in workers

 

 

Use docker for flashing an opensource Zigbee Router

 Following this procedure to increase my Zigbee network range (works amazing !), I've ended up with another method of using cc-tools :

https://www.zigbee2mqtt.io/how_tos/how_to_create_a_cc2530_router.html

At the end of step2., this is given to perform https://www.zigbee2mqtt.io/how_tos/how_to_create_a_cc2530_router.html procedure, which is very similar.

Using cc-tools was a burden for me as I use a hybrid testing/stable debian, I could not get all the dependencies solved.

I've found some docker images : https://hub.docker.com/search?q=cc-tool&type=image

So I've used joonas' one

Here is the command :

- perform 'lsusb' to get the device bus ID of the Texas Instrument flashing device.

- download the firmware image in /dest/ and bind mount it in /srv

- joonas/cc-tool:latest does not exist, so it is mandatory to use the correct image tag

docker run -it --device /dev/bus/usb/001/021 -v /dest/CC2530_CC2591_router_2020_09_29:/srv joonas/cc-tool:20210112_1334_98a05cdf cc-tool -e -w /srv/router-cc2530-cc2591-std.hex

Secure Fortigate Virtual Server

 By default, the settings for a Fortigate virtual server are not considered secure on this website : https://internet.nl/site/ or https://www.ssllabs.com/ssltest/analyze.html

 

Current FortiOS version is 6.4.4 so custom ciphers should not be used, as the traffic is not processed afterwards (bug ?)

 

The list :

 

TLS 1.1 phased out

cyphers phased out :

• ECDHE-ECDSA-DES-CBC3-SHA [1.0]
• ECDHE-RSA-DES-CBC3-SHA [1.0]
• DHE-RSA-DES-CBC3-SHA [1.0]
• AES256-GCM-SHA384 [1.2]
• AES128-GCM-SHA256 [1.2]
• AES256-SHA256 [1.2]
• AES256-SHA [1.0]
• AES128-SHA256 [1.2]
• AES128-SHA [1.0]
• DES-CBC3-SHA [1.0]

DH-2048 Key exchange phased out

Client-initiated renegotiation

Here are the settings to avoid it :

conf firewall vip

edit <vip_name>

        set ssl-dh-bits 3072
        set ssl-algorithm custom
        config ssl-cipher-suites
            edit 1
                set cipher TLS-AES-256-GCM-SHA384
                set versions tls-1.2 tls-1.3
            next
            edit 2
                set cipher TLS-CHACHA20-POLY1305-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 3
                set cipher TLS-AES-128-GCM-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 4
                set cipher TLS-AES-256-GCM-SHA384
                set versions tls-1.2 tls-1.3
            next
            edit 5
                set cipher TLS-CHACHA20-POLY1305-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 6
                set cipher TLS-AES-128-GCM-SHA256
                set versions tls-1.2 tls-1.3
            next
        end
        set ssl-min-version tls-1.2
        set ssl-client-renegotiation deny

end

end

restrict SFTP to a user and specific directory

 create a SSH Subsystem :

#Subsystem      sftp    /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
  Match group sftpusers
  ChrootDirectory %h
  ForceCommand internal-sftp

restart ssh server

create a user member of sftpusers:

sudo useradd -g sftpusers -s /sbin/nologin -m -d /directory/to/share username

Apply permissions for Chroot


As ChrootDirectory needs to belong to root and have 755 permissions :

chown root: /directory

chown root: /directory/to

chown root: /directory/to/share

and also apply 755 permissions to these

apply the wanted permissions for the shared directory

chown -R user1:sftpusers /directory/to/share/*

Calico does not insert iptables rules

on kubernetes pod had  a DNS issue, it could not reach the outside. The Fortigate firewall was not receiving the packet.

Only one node was affected, and this node was an updated Debian Buster image from Stretch.

The difference is that Buster uses now nftables instead of iptables.

so there is the iptables command and the iptables-legacy.

I could see that the iptables -L command was not being populated with calico inputs, and instead these rules were added in iptables-legacy.

This is due to the fact that calico still uses the old iptables.

In order to make everything work, I use only the iptables-legacy :

update-alternatives --set iptables /usr/sbin/iptables-legacy

this is a known Calico issue #2322 : https://github.com/projectcalico/calico/issues/2322

External email with OVH mail on proxmox

configure the /etc/postfix/main.cf like the below

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

#CHANGEME
myhostname=proxmox1.gatom.net

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
#mydestination = $myhostname, localhost.$mydomain, localhost
#relayhost =
mynetworks = 127.0.0.0/8
inet_interfaces = loopback-only
recipient_delimiter = +

compatibility_level = 2

# OVH SMTP/TLS
relayhost = [ssl0.ovh.net]:465
smtp_use_tls=yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_security_options = noanonymous

smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt

the two last are required for SMTPS or error message is :

(TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger)

add credentials to /etc/postfix/sasl_passwd

 [ssl0.ovh.net]:465     login:password

set permissions

chmod 600 /etc/postfix/sasl_passwd

create the password db

postmap /etc/postfix/sasl_passwd

of the db is not correct with the given credentials, error is

(SASL authentication failed; server ssl0.ovh.net[193.70.18.144] said: 535 5.7.1 Authentication failed)

install the package for sasl

apt-get install libsasl2-modules

otherwise error is

(SASL authentication failed; cannot authenticate to server ssl0.ovh.net[193.70.18.144]: no mechanism available)

restart postfix

systemctl restart postfix

test

echo "test ok" | mail -s "Test" dest-email@domain.com

 

change Ceph permissions

ceph auth list

...
client.cloud
    key: AQB6hPddq....HcQpUMPSNunT2w==
    caps: [mds] allow rw path=/nas/path/1, allow rw path=/nas/path/2
    caps: [mon] allow r
    caps: [osd] allow rw pool=cephfs_data
...

change with :

ceph auth caps client.cloud \
     mon 'allow r' \
     osd 'allow rw pool=cephfs_data' \
     mds 'allow rw path=/nas/path/1, allow rw path=/nas/path/3'

then check with ceph auth list

...
client.cloud
    key: AQB6hPddq....HcQpUMPSNunT2w==
    caps: [mds] allow rw path=/nas/path/1, allow rw path=/nas/path/3
    caps: [mon] allow r
    caps: [osd] allow rw pool=cephfs_data
...

LoadBalance Service for Bare metal / VM Kubernetes : Metallb

I use Metallb for the LoadBalance service of my kubernetes cluster.

helm install metallb --namespace=metallb stable/metallb

apply the configmap that is the default for the chart.

remember that for the Helm chart the configmap name has to be metallb-config, which is different from the metallb documentation.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
        - 10.0.14.100-10.0.14.200

I prefer the BGP implementation :

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb
  name: metallb-config
data:
  config: |
    peers:
    - peer-address: 10.0.14.1
      peer-asn: 64501
      my-asn: 64500
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.0.12.128/25

I peer the BGP peers with the Fortigate firewall which is 10.0.14.1 :

config router bgp
    set as 64501
    set router-id 0.0.0.1
    config neighbor
        edit "10.0.14.11"
            set remote-as 64500
        next
        edit "10.0.14.12"
            set remote-as 64500
        next

        ... (and the remaining nodes)

        next
    end
    config redistribute "connected"
    end
    config redistribute "rip"
    end
    config redistribute "ospf"
    end
    config redistribute "static"
    end
    config redistribute "isis"
    end
    config redistribute6 "connected"
    end
    config redistribute6 "rip"
    end
    config redistribute6 "ospf"
    end
    config redistribute6 "static"
    end
    config redistribute6 "isis"
    end
end

do not forget to open the firewall rules then.

reference for the Helm chart :

https://hub.helm.sh/charts/stable/metallb

Ceph for Kubernetes

follow :
https://github.com/kubernetes-incubator/external-storage/

Straight forward with some modifications, as the claim has to have a different name, and pay attention that for CephFS and RDB, the admin secret name is different, but can be set the same.

I also used the same cephfs namespace for both.

EDIT : I made a PR that uses now the same kubernetes user for both storageclass
here : https://github.com/kubernetes-incubator/external-storage/pull/1306

ZFS storage driver for docker

This is used to have a docker setup directly on Proxmox 6 with ZFS 


stop the docker service

service docker stop


delete all the docker stuff

rm -rf /var/lib/docker


create a zfs pool dedicated for docker
  
zfs create -o mountpoint=/var/lib/docker rpool/docker


create the systemd entry for the docker service

mkdir /etc/systemd/system/docker.service.d


setup the driver for docker

nano /etc/systemd/system/docker.service.d/storage-driver.conf


[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --storage-driver=zfs -H fd://


then restart daemons and docker

systemctl daemon-reload
service docker start





Samba over CephFS

I wanted to use NFS to share data on the network, but Windows 10 still isn't able to use NFS ... what a joke.

So first mount CephFS (see previous article)

Then configure the Samba server

1. install samba server 

apt-get install samba

2. edit the configuration file

set the workgroup

add a samba share, for example

[photos]
        comment = photos
        read only = no
        path = /mnt/cephfs/nas/photos
        guest ok = no
 

2. configure users

I use the same setup users as the user on the windows machine

add the user :

adduser toto

setup its password: 

passwd toto

then add this user to Samba :

smbpasswd -a toto

then restart the daemon to take into account the config :

systemctl restart smbd 

proxmox HTTPS certificates for load balancing

generate a PKI and trust the Root CA in your browser (using XCA ?)
I used the CN as proxmox.domain.net, and then SAN to every proxmox$i.domain.net to use the same certificate for every node and the Virtual Server IP of the Load balancer (here the Fortigate)

export the certificate chain without the CA(.crt) and the key (.pem)

then copy on every node :


for i in {1..n}; \
do \
scp proxmox.domain.net.crt proxmox5:/etc/pve/nodes/proxmox$i/pve-ssl.pem; \
scp proxmox.domain.net.pem proxmox5:/etc/pve/nodes/proxmox$i/pve-ssl.key; \
ssh proxmox$i systemctl restart pveproxy;\
done



Then I use the Fortigate to load balance :
https://docs.fortinet.com/document/fortigate/6.2.3/cookbook/713497/virtual-server

Kubernetes

Dashboard :

the URL is
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

in order to login with the config file in .kube/ folder, add the token of a service account with privileges (here cluster admin) :

get the token for user <toto>

TOKEN=$(kubectl -n kube-system describe secret toto| awk '$1=="token:"{print $2}')

add it to the config file :

kubectl config set-credentials kubernetes-admin --token="${TOKEN}" 

Waiting for Quorum on Proxmox

When an addition of a node to the cluster fails, there is the message 'waiting for quorum...' and on the GUI it is 'Invalid PVE Ticket' and you cannot login anymore.

Here is my script to retry a failed cluster :

systemctl stop pve-cluster.service
systemctl stop corosync
pmxcfs -l
rm /etc/pve/corosync.conf
rm -Rf /etc/corosync/*
killall pmxcfs
systemctl start pve-cluster.service

rm -Rf /etc/pve/nodes/proxmox5

echo "#### NOW on a cluster member, remove previous reference in these files:

root@proxmox1:~# rm -Rf /etc/pve/nodes/proxmox5
root@proxmox1:~# nano /etc/pve/corosync.conf
root@proxmox1:~# rm -Rf /var/lib/corosync/*
"

remote CEC server for Home assistant

I wanted to connect my Home assistant to the TV, so the pycec module on home assistant can connect to a Raspberry Pi that is connected to the TV and can be connected to Home assistant via TCP/IP.

I used this repository :
https://github.com/konikvranik/pycec/

First, enable the pycec module on home assistant.
In the configuration.yaml file, add :

hdmi_cec: !include config/hdmi_cec.yaml

and in the config/hdmi_cec.yaml file :

host: !secret rpi3b_ip

Then on the Raspberry pi :
cd
git clone  https://github.com/konikvranik/pycec/

First, compile the libcec :
https://github.com/Pulse-Eight/libcec

For compiling it, I followed the Linux procedure :

apt-get update
apt-get install cmake libudev-dev libxrandr-dev python-dev swig
git clone https://github.com/Pulse-Eight/libcec.git
mkdir libcec/build
cd libcec/build
cmake ..
make -j4
sudo make install
sudo ldconfig

Then symlink the service in the pycec repository :
ln -s /path/of/pycec.service /etc/systemd/system/pycec.service
systemctl start pycec

then enable the service so it starts at boot :
systemctl enable pycec

restore ceph admin rights

I did overwrite the client.admin entry by importing a wrong keyfile. So I could not manage the cluster again.

The only solution was to deactivate cephx authentication on the cluster by changing the configuration file to :

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

and then restart the ceph daemons on each node. As I'm using proxmox, I had to use the systemctl:

systemctl restart ceph.target 

source :

https://docs.ceph.com/docs/emperor/rados/operations/authentication/

then import the admin profile with full rights 

Then put the authentication back and restart the daemons.

connect Debian to Proxmox CEPH cluster and mount Cephfs

on client create the destination directory

mkdir -p /etc/pve/priv/

copy the keyring on the debian client: (uses admin keyring !!)

scp <proxmox_ip>:/etc/pve/priv/ceph.client.admin.keyring /etc/pve/priv/.

copy the configuration file :

scp <proxmox_ip>:/etc/pve/ceph.conf /etc/ceph/.

test

ceph status

#####

mount Cephfs on debian

1. on ceph:


generate a keyfile for client foo on proxmox:

ceph auth get-or-create client.foo \

    mds 'allow rw path=/ceph/mount/point' \

    mon 'allow r' \

    osd 'allow rw pool=cephfs_data' \

    -o /etc/pve/priv/ceph.client.foo.keyring

check the client with :
ceph auth list

generate a minimal config :
ceph config generate-minimal-conf

and copy the output in /etc/ceph/ceph.conf on the client

2. on client:

aptitude install libcephfs2 ceph-common ceph-fuse 

copy the keyring file from the client

mkdir -p /local/mount/point

add an entry in /etc/fstab like :

id=foo,conf=/etc/ceph/ceph.conf,client_mountpoint=/ceph/mount/point /local/mount/point fuse.ceph _netdev,defaults 0 0

_netdev here is important, otherwhise it does not boot 

3. then mount it 

sudo mount -a 

migrating from XCP-ng (xen) to Proxmox (LVM)

create the VM, be the closest to the XCP-ng VM on Proxmox
detach the disk

export the VM with Xencenter in ova/ovf format (GUI)

extract the ova : 

tar -xvf <ova_file.ova>
this result in a vhd + ovf file

convert the filedisk format:

qemu-img convert -f vpc <disk_file.vhd> -O qcow2 <disk_filename.qcow2>

import the disk to the vm :  

qm importdisk <vm_id> <disk_filename.qcow2> <storage> -format qcow2

attach the disk to the vm, then boot