Posts by luxflow

    encryption: I used letsencrypt to generate an SSL cert for remote access; I created OMV self signed certs for each lan service

    I'm not sure why you do, I think there is no difference self signed vs letsencrypt cert for lan services since either self or letsencrypt
    it should be added trusted cert by manually to all of your computer which trying to lan services



    nginx: I created a pair of servers - one for remote; another for lan. In all servers, I am using SSL on 443 and selecting the appropriate certificate

    try your Server name : emby.mydomain.com emby.lan
    to manage only one configuration per service





    Emby:


    I can't get it to work on port 8920. I just get an nginx error. Should I be using this port if I am using nginx with SSL:443/certificate? I have attached my emby nginx settings.

    8920 port should be used when emby uses https (for SNI proxy), so your case, 8096
    you should differentiate meaning between
    proxy server using https and
    service using https or http


    for example, if proxy server uses https and service use http, when user connect proxy server, connection between user and service is https
    1. user < -(https)- > proxy server
    2. proxy server < -(http,https)- > service
    In your case, your service is safe either http or https
    because your service listen at localhost, user in LAN cannot directly access to service, only can access via proxy server


    Usually service don't provide https
    Because usually people use proxy server, and hide their service from directly access (for security reason, and load balacing, easy cert management)


    SNI proxy says it is for
    This enables HTTPS name-based virtual hosting to separate backend servers without installing the private key on the proxy machine.


    But, in your case your proxy machine server and backend service server(emby...) are in same server, so SNI proxy for you is meaningless I think..

    There are 3 options I think


    first of all, In all 3 options, your services should be listen at localhost(127.0.0.1)
    that means all connection should pass proxy (whatever it is nginx, SNI..) unless connection made from OMV machine itself


    First, very simple, easiest to configure but give up to use


    (2) set up a way of mapping emby.xxx.local to 127.0.0.50:8096 (which is for lan access);

    instead make `server_name emby.local emby.mydomain.com`
    or give up to use local address, access service only via emby.mydomain.com


    Second,
    set up omv-nginx for remote access
    and set up omv-nginx for lan access (that means `server_name emby.mydomain.com emby.local`)
    this can be done with omv-nginx UI


    Third,
    unlike above options, set your services to serve https
    set up omv-nginx for remote access (that means `emby.mydomain.com localhost:8920`)
    and set up omv-nginx for lan access (that means `emby.local localhost:8920`) note 8920 is https for emby


    also don't forget to setup local dns, such as mDNS, DNS whatever... if you want to local domain
    If you use option second, third one, you will encounter cert security warning this when you connect services from LAN
    unless you manually add cert to trusted cert


    My recommended choices are
    first one or second one

    why are you trying to copy cert not just using reverse proxy?
    just use omv-nginx


    like this..


    1st OMV as proxy server (https) <------------> services on 2nd OMV (http)
    |
    services on 1st OMV

    raid is for availability
    raid is not backup
    for example raid cannot protect user's mistake, virus..
    then why use raid? because of availability
    think about running company, using raid 1 with 2disks
    one disk fail, but it can stil serve service, that means it is available


    so best practice is.. having both availability and backup


    so back to the your problem
    for home user, backup is more important than availability
    my suggestion is grabbing `addition` hard disk (should be seperated hard disk don't put your eggs in same basket)
    and rsync(similar copy, but only changed part is copied) important data to another disk

    hmm try omv-nginx plugin rather than SNI proxy
    it is more convinient sice it has web UI
    I googled some info about SNI proxy and I think you don't need SNI proxy


    so basically set your backend services(emby,syncthing..) to use http (it is default as I know)
    and using nginx as reverse proxy, of course you can assign different port for each backend service


    but I suggest you different hostname for services rather than only changing port if you possible
    so
    use syncthing.example.com, emby.example.com
    rather than example.com:445, emby.example.com:446
    I think it is more good practice


    for example, emby listen http://localhost:8096


    so omv-nginx -> server -> add -> follow below setting (change domain, port according to your needs)


    and put it in extras options

    all cert information is stored at /etc/letsencrypt/
    so basic idea is copy that folder to the other omv
    it can be done with scp, or rsync cronjob


    but problem is
    it copy only cert file, don't copy omv configuration
    so you cannot see cert in omv interface


    so you have to make script for adding cert configuration for omv gui


    but don't know why you want to use same cert
    so I cannot give you advice further

    oh I found what's wrong with you


    just type following commands


    git clone https://github.com/dlundquist/sniproxy
    cd sniproxy
    sudo apt-get install autotools-dev cdbs debhelper dh-autoreconf dpkg-dev gettext libev-dev libpcre3-dev libudns-dev pkg-config fakeroot devscripts./autogen.sh && dpkg-buildpackagesudo dpkg -i ../sniproxy_<version>_<arch>.deb


    you might wonder why git clone, cd sniproxy is skipped in github page
    that's because usually plugin developer expect user already know this procedure


    although it is.. more like about linux not OMV
    next time, ask in linux forum, or freenode #irc
    you will get better faster answer

    yeah that is nfs share problem will be fixed in next release
    workaround is


    0. unmount all zfs filesystem
    zfs umount -a


    1. ensure your zfs filesystem is not mounted
    zfs get mounted -t filesystem


    1.5 double check there is file in /GHpool to prevent deleting your data
    ls /GHpool
    ls /GHpool/blahblah...


    2. rm -rf /GHpool


    3. remount zfs mount -a

    do you use NFS share for ZFS?
    if so current(3.0.6) implementation has problem, will be fixed (3.0.7) which will be released with omv 3.0.60 (it is not released also)


    if not,
    checkout systemctl status zfs-mount to see why it is not mounted
    zfs get mounted -t filesystem

    I'm considering passing --rsa-key-size argument whenever calling certbot


    What I concern is that changing rsa key size 4096 may be drop supports for older browser
    also as I don't think it is urgent thing to be fixed. it will takes time..

    by defaults, omv redirect all host to admin page (that means admin.my.url, game.my.url, media.my.url will be redirected to web gui)


    if you want to add virtual host such as (such as game.my.url, media.my.url)
    use omv-nginx plugin to add virtual host


    if you don't have plan to add virtual host but change web gui address for admin page
    add OMV_NGINX_SITE_WEBGUI_SERVERNAME="admin.my.url" in /etc/default/openmediavault
    (why this works?, see here)

    you can change chiper for omv web gui as you want (see here)
    so you just add OMV_NGINX_SITE_WEBGUI_SSL_CIPHERS="EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH" in /etc/default/openmediavault
    not to use DH keys


    for RSA key length 4096, should have to chnage omv-letsencrypt to support it
    but not sure when that feature is released