FlexMcMurphy's questions

I am using a script to make a backup of a running Debian Stretch based Linux Distro (NextCloudPi)

The method in the script that does the backup uses rsync.

backup()
{
  mntimg
  sync
  rsync -aDH --partial --numeric-ids --delete --force --exclude "${MNTPATH}" --exclude '/dev' --exclude '/lost+found' --exclude '/media' --exclude '/mnt' \
--exclude '/proc' --exclude '/run' --exclude '/sys' --exclude '/tmp' --exclude '/var/swap' --exclude '/etc/udev/rules.d/70-persistent-net.rules' \
--exclude '/var/lib/asterisk/astdb.sqlite3-journal' "${OPTIONS[@]}" / "${MNTPATH}/"
..
..
}

When I run the script I point it to save the backup .img file to an externally attached USB-HDD drive.

This drive is EXT4 formatted and is mounted.. I can browse it from Manjaro file explorer. This is writable and has 2.3TB free space.

The backup file is going to be about 7.8GB and I have got 22GB free space on the rootfs (/) on the SD Card that I am backing up.

Each time I run the script I get an error rsync: write failed on.. no space left on device:

root@NEXTCLOUDPI:~# image-backup

Image file to create? /media/4TB2/nextcloudpi18Nov2021v3.img

Initial image file ROOT filesystem size (MB) [7526]? 7800

Added space for incremental updates after shrinking (MB) [0]? 

Create /media/4TB2/nextcloudpi18Nov2021v3.img (y/n)? y

Starting full backup (for incremental backups, run: /usr/local/bin/image-backup /media/4TB2/nextcloudpi18Nov2021v3.img)
rsync: write failed on "/tmp/img-backup-mnt/usr/src/linux-headers-4.14.93-Re4son-v7+/include/linux/suspend.h": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

Unable to create backup

root@NEXTCLOUDPI:~#

I still get the problem even if I add in the rsync option --inplace so that did not solve my problem.

I did a sudo du -sh /usr/src and the size is 150MB.
I've got 37,000 files and 12,000 sub-folders in /usr/src so I was thinking maybe I am running out of inodes but... I did a df -i and my inode usage is 14% in the root dir (/).

The problem seems to happen close to the end.. in this case a 7.9GiB file is created. I tried flashing that to an sd card with etcher but it didn't boot.

Any ideas what is going wrong here? I have enough space on the rootfs for rsync to save things to /tmp if it needs to. But even when I use the --inplace option it still says: rsync: write failed on "/tmp/... blah blah... No space left on device (28)

I want to ssh from one host (OpenWrt running Dropbear) to another host on the same LAN that is running open-ssh server and client.

I converted the private open-ssh key of the other host to dropbear format and saved it to ~/.ssh/ncp_key_dropbear on the OpenWrt host.

Now I can ssh from OpenWrt to the other host like this:

# ssh -i ncp_key_dropbear [email protected] -p 22

I also made a ~/.ssh/config file on the OpenWrt host like this:

Host ncp
        User root
        Port 22
        IdentityFile ~/.ssh/ncp_key_dropbear
        HostName 192.168.1.124

But when I try to ssh now with this command:

# ssh ncp

I get this error...

root@OpenWrt:~/.ssh# ssh ncp

ssh: Connection to root@ncp:22 exited: Connect failed: Error resolving 'ncp' port '22'. Name does not resolve

Actually I get the same error even if I change the Port to 1022 even though the sshd on the remote host is also listening on that port.

I set up a ~/.ssh/config file on the other host as above, except I use an open-ssh client on that host, and can ssh from it to OpenWrt like this:

# ssh openwrt

So why is my config file not working on the OpenWrt? Does Dropbear not know anything about ~/.ssh/config files? Here is an article from 2009 that seems to suggest that but surely things have changed?

Cheers,

Flex

I want to run this url: https://192.168.1.254 and get a website with the correct content and certificate in the address bar. I am getting the website but I get an invalid certificate error in the address bar because the cert is taken from a different server block: the default server block 000-default.conf.

Can someone explain this behavior to me please?

My client browser is Google Chrome Version 87.0.4280.88 (Official Build) (64-bit)

My Nginx server is:

root@OpenWrt:/etc/nginx/conf.d# nginx -V
nginx version: nginx/1.19.4 (x86_64-pc-linux-gnu)
built with OpenSSL 1.1.1h  22 Sep 2020
TLS SNI support enabled

I think the issue is related to how SNI apparently does not allow a Literal IPv4 and IPv6 addresses as a "HostName". But is that really the case?

I have a default server block 000-default.conf like this:

server {
    server_name _;
    listen 80 default_server;
    listen 443 ssl default_server;

    ## To also support IPv6, uncomment this block
    # listen [::]:80 default_server;
    # listen [::]:443 ssl default_server;

    ssl_certificate '/etc/nginx/conf.d/_lan.crt';
    ssl_certificate_key '/etc/nginx/conf.d/_lan.key';
    return 404; # or whatever
}

And another server called luci-http.conf like this:

server {
        listen 80;
        listen [::]:80;
        server_name openwrt.lan 192.168.1.254;
        # access_log /proc/self/fd/1 openwrt; # use logd (init forwards stdout).
        include conf.d/*.locations;
}

When I put http://192.168.1.254 in the address bar it serves me up the correct webpage.

I also have this https server: luci-https.conf

server {
        listen 443 ssl;
        listen [::]:443 ssl;

        server_name openwrt.lan 192.168.1.254;
        #include '/var/lib/nginx/lan_ssl.listen.default';
        ssl_certificate '/etc/nginx/conf.d/_lan.crt';
        ssl_certificate_key '/etc/nginx/conf.d/_lan.key';
        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';
        # access_log /proc/self/fd/1 openwrt; # use logd (init forwards stdout).
        include conf.d/*.locations;
}

When I put https://192.168.1.254 in the address bar it serves me up the correct webpage and the certificate in _lan.crt. As you can see I have the same Cert/Key pair in this and the default server block.

However when I remove that ip address as a server_name from luci-https.conf and add it as a server_name in: mysite.lan.conf I don't see the same behavior.

server {
        listen 443 ssl;
        listen [::]:443 ssl;
        #listen 192.168.1.254 ssl;
        #include '/var/lib/nginx/lan_ssl.listen';

        server_name mysite.lan www.mysite.lan fun.mysite.lan 192.168.1.254;

        root /www/mysite;
        index index.html index.htm index.nginx-debian.html;

        ssl_certificate '/etc/nginx/conf.d/mysite.lan.crt';
        ssl_certificate_key '/etc/nginx/conf.d/mysite.lan.key';
        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';

        location / {
                try_files $uri $uri/ =404;
        }

        access_log /var/log/nginx/mysite.lan.access.log;
        error_log /var/log/nginx/mysite.lan.error.log;
}

Now when I put https://192.168.1.254 in the address bar it serves me up the correct webpage but again the certificate in _lan.crt not the certificate: mysite.lan.crt from mysite.lan.conf as expected.

When I put..

ssl_certificate '/etc/nginx/conf.d/mysite.lan.crt';
ssl_certificate_key '/etc/nginx/conf.d/mysite.lan.key';

in the default server block 000-default.conf then I get that certificate instead when I put https://192.168.1.254 in the browser address bar whether 192.168.1.254 is specified as a server_name in luci-https.conf or mysite.lan.conf.

So it seems that SNI will match on a "hostname" that is an ip address but it takes the certificate from the default server block. Why is that?