Posts by johnlocke

  • NASA build. 6x HDD, internal UPS in small 11 litres aluminium case

    Cockpit SSL certs


    Code
    systemctl stop cockpit

    cp /etc/letsencrypt/live/host.domain.com/fullchain.pem /etc/cockpit/ws-certs.d/host.domain.com.crt

    cat /etc/letsencrypt/live/host.domain.com/privkey.pem >> /etc/cockpit/ws-certs.d/host.domain.com.crt

    remotectl certificate  # check what cert will be used

         # certificate: /etc/cockpit/ws-certs.d/host.domain.com.crt

    systemctl start cockpit

    tail -f  /var/log/syslog | grep cockpit

  • NASA build. 6x HDD, internal UPS in small 11 litres aluminium case

    The M.2 to 5x SATA card overheated on heavy disk ops, so I put a heat sink on JMB585 chip. Its custom cut for size and I drilled two holes in the floor to tie it. Ahh, and there is foam sticked to card bottom, PCB is very thin, it adds support when plugging SATA cables in.


    The errors were crazy, disk was remounted as read only, but snapraid continued writing on data2 :))


    The card I used is IO Crest SI-ADA40141 JMB585 is surprisingly fast.

  • Omv5 and Letsencrypt plugin

    Quote from ryecoaaron

    There is a plugin that does this but I stopped maintaining it because certbot is a moving target

    Yes, plugin following another piece of sw is a pain. But I think its not needed, just giving users a way to enter path to their certificates will be sufficient, imho. They already have autorenewal configured by other means (I use acme.sh and dns-01 validation).

  • Cockpit does not use OMV's SSL certificate

    I installed Cockpit from OMV Extras and my browser refuses to connect to it because of self-signed SSL cert and used URL is not IP but omv.domain.name FQDN.


    OMV GUI is working nice, with SSL cert configured in System / General.


    Why Cockpit (omv.domain.name:9090) is presenting self-signed cert and not the OMV GUI one, and how to fix it, please?
    Side note, Cockpit looks much more secure than Portainer, using real OMV user accounts for login.

  • Review my NAS configuration (Ryzen, ECC)

    Quote from The_Others

    I did have a look at FreeNAS and it does look promising, but when reading more about free NAS solutions I read a remark that FreeNAS is open BSD based and OMV is based on Debian

    This is not a big issue with FreeNAS, the issue is memory. Before deciding on OMV (+snapRaid) I installed FreeNAS. It looked nice :)) Then I checked memory usage. It was at 2.5GB and slowly creeping up. Without any data drives attached! Some python processes, lots of them. And in docs they say 1GB RAM per one data drive, so I uninstalled it. OMV does not use any RAM it looks like :))

  • NASA build. 6x HDD, internal UPS in small 11 litres aluminium case

    Quote from riff-raff

    I use 2 NAS in 2 different locations, the opposite keyfile for encryption lies on the other NAS.

    Interesting, very! I dont have second NAS, lol. Is your OS partition encrypted too?


    My points against remote keyfile:

    - system needs to come live by itself after power outage.

    - OS must be encrypted and keyfile for OS drive needs to be local to auto boot.

    - OS drive keyfile shoud be hard to access, hence TPM.


    If OS is secured, it is safe to store data drives keyfile there. If not, whats the point of encrypting at all?

    Btw, my steps for data drives.

  • Omv5 and Letsencrypt plugin

    Quote from macom

    https://openmediavault.readthe…general/certificates.html

    So there is no way to specify path to cert and key files? Only hard import available? How do we do automatic renewal using cron jobs then? The renewal command updated cert files on the disk, not in OMV database ...

    I see that in /etc/nginx/sites-available/openmediavault-webgui it links to uuid-ed files.


    Code
    ssl_certificate /etc/ssl/certs/openmediavault-xxxxx-xxxx-xxxx-xxxxxxx.crt;

    ssl_certificate_key /etc/ssl/private/openmediavault-xxxxx-xxxx-xxxx-xxxxxxx.key;

    Will it work, and stay working, If I do

    Code
    cd /etc/ssl/certs/

    rm openmediavault-xxxxx-xxxx-xxxx-xxxxxxx.crt

    ln -s /real/path/to/mysite.crt openmediavault-xxxxx-xxxx-xxxx-xxxxxxx.crt

    (plus same for key)

  • MiniGuide: Auto unlock LUKS volumes on boot. Works with MergerFS+SnapRaid too.

    Hi guys.


    First, thanks a lot for OMV.

    I was following this guide michaelxander.com/diy-nas till I hit "After every reboot, all encrypted drives need to be unlocked through the Web UI".


    That did not seem right, if we dont trust our OS to keep LUKS key, why we trust the whole setup? Encrypting root partition is not part of this mini guide, it's a must, but will be next step. This only makes all encrypted data drives auto-unlocked, mounted and in a MergerFS pool on boot.


    - these steps do not mess with /etc/fstab :)

    - sda, sdb and sdc are data drives (data and parity). Its not where OS is installed (my OS drive is mmcblk0)

    - wdkey - can be any name, as well as /etc/luks-keys (you may use /root/keyfile for example)

    - assuming clean install and drives configured exactly as in michaelxander's guide (stop after doing 4.5. Create MergerFS pool).


    1. generate keyfile

    dd if=/dev/urandom of=/etc/luks-keys/wdkey bs=1024 count=4

    chmod 0400 /etc/luks-keys/wdkey


    2. add key to a LUKS slot

    cryptsetup -v luksAddKey /dev/sda /etc/luks-keys/wdkey

    cryptsetup -v luksAddKey /dev/sdb /etc/luks-keys/wdkey

    cryptsetup -v luksAddKey /dev/sdc /etc/luks-keys/wdkey

    Enter any existing passphrase:

    Key slot 0 unlocked.

    Key slot 1 created.

    Command successful.


    3. create /etc/crypttab

    /etc/crypttab is read before fstab, so that dm-crypt containers can be unlocked before the file system inside is mounted.


    The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that device is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/dm_name so as not to overwrite the encrypted data.


    Use blkid to get uuid (Use uuid of /dev/sdx ones, not /dev/mapper/sdx-crypt). No new line at the end.

    The fist item in each line, target, "sda-crypt", must be equal to output of blkid : "/dev/mapper/sda-crypt"


    vi /etc/crypttab (Content should look like this)

    sda-crypt UUID=2505567a-9e27-4efe-a4d5-15ad146c258b /etc/luks-keys/wdkey luks

    sdb-crypt UUID=12345678-9abc-def012345-6789abcdef01 /etc/luks-keys/wdkey luks

    sdc-crypt UUID=c67c557c-21b9-11eb-82d8-170fd1bb7315 /etc/luks-keys/wdkey luks


    chmod 400 /etc/crypttab


    4. backup luks headers

    Encryption > Select drive > Recovery > Backup


    5. Thats it, reboot

  • NASA build. 6x HDD, internal UPS in small 11 litres aluminium case

    To be continued for sure.


    MB: Seeed Studio Odyssey X86J4105864. $218 USD

    - Intel® Celeron® J4105, Quad-Core 1.5-2.5GHZ

    - 8 GB RAM, soldered on, max for this CPU

    - 64 GB eMMC for OS, soldered on

    - Dual-Band Frequency 2.5GHz/5GHz WiFi/ Bluetooth 5.0

    - Dual intel Gigabit Ethernet

    - Integrated Arduino Coprocessor ATSAMD21 ARM® Cortex®-M0+

    - Raspberry Pi 40-Pin Compatible

    - 2 x M.2 PCIe (B Key and M Key)


    SATA:

    - M.2 to 2x SATA card (M.2 to 5x SATA card also bought)


    Case:

    - Jonsbo U1 Plus Silver Mini ITX Case w/Tempered Glass

    - 2x ICYDOCK 3 Bays SCSI U160 Disk Array Module. $10 each, backplane removed.

    - 5 Inch Touch Display for Raspberry pi 3. $35. Will be mounted behind tempered glass side panel.


    Power: AC adapter -> DFRobot -> Regulator -> drives and MB

    - DFRobot DFR0580. Power Manager For 12V Lead-Acid Battery

    - AC adapter 24V/4.5A inside the case

    - DC-DC regulator 9-18V to 12V/12A

    - Power Sonic PS1220 12V 2.5AMP SLA Lead Acid Battery. About 15 mins run time with 6x HDD. I will use embedded Arduino to shut down the OS if battery goes below 10V.