Posts by pcon

    Wake-On-Lan (WOL)


    Wake on Lan is a process in which a computer is switched on remotely by means of a so-called "Magic Packet". WOL must always be supported by the device to be switched on. In most cases, there is a corresponding setting in the BIOS that must be activated. Without WOL support, an automated shutdown makes no sense, because the server always has to be started manually.


    Supports the device WOL, it is sufficient to edit the Ethernet interface (under the condition that the server hangs via Ethernet connection in the network) in the OMV control panel under Network in the Interfaces tab. In the Advanced Settings area, WOL must be activated.


    OMV is just an essay for Debian. Therefore, settings can also be made on the command line. If you prefer to make changes here, you can do this using Ethtool. The current configuration can be checked using the following commands:


    ethtool eth0


    With WOL activated, the output should contain the following two:


    Supports Wake-on: pumbg

    Wake-on: g


    To activate WOL automatically when starting the system, the passage to the Ethnernet interface in /etc/network/interfaces must be completed by the following line:


    eth0 network interface auto eth0 allow-hotplug eth0 iface eth0 inet dhcp pre-down ethtool -s $IFACE wol g iface eth0 inet6 manual pre-down ip -6 addr flush dev $IFACE


    It is definitely easier to do the configurationin the OMV control panel, but you can check at the commando line if it doesn't work as it should.


    Advice: change eth0 with your interface name.


    Autoshutdown


    To automatically shut down the server, the corresponding package must first be installed:


    apt-get install openmediavault-autoshutdown


    This is an exclusive function of OMV. A normal Debian system can be shut down on a time-based basis, but not according to certain criteria, for example. In the OMV control panel, the function can be configured in the Services section under Automatic shutdown.


    If there are problems, have a look at the log file of the autoshutdown. Located ad:


    /var/log/openmediavault-autoshutdown.log


    To view the logfile you can use the cli Tools: less or tail.


    less /var/log/openmediavault-autoshutdown.log


    tail -f /var/log/openmediavault-autoshutdown.log


    The less command allows you to view the log file and tail -f will continuosly display new log entries as the are written.

    Think about a backup and restore for your data. You have Build a RAID 1 for your NAS. RAIDs are for continuity in working with the data but RAID doesn’t replace a backup and a restore for your data.


    In the most cases home users don’t need a NAS for continuity in working. Your NAS System is not build redundancy. RAIDs can be a point that causes issues. So it make more sense for you NAS to use the HDD without a RAID System.


    For a backup and restore you can use software like: Duplicaty, Borg Backup, ….


    Here you can found another topic: My thoughts about... RAID

    The easiest way is to ask Vodafone for an IPv4 or dual stack and hope that the boys and girls at Vodafone will change it.


    Other options could be tunnels on a VPS or Cloudflare basis. But try the Vodafone option first as this is the best option if you want to get IPv4 and IPv6 on your internet connection.

    He has configured WireGuard with the Fritz!Box (FB). Port forwarding and other stuff will be done automatically by the FB. He has written in #5 that the connection from the WireGuard connection from the external Laptop to the FB can be established.

    https access with Jellyfin:

    You can upload a certificate to your Jellyfin instance and enable the https in Jellyfin. Now you can access the Jellyfin with https.

    https://JellyfinIpAddres:8920/


    Enable https port forwarding for on the Fritz!Box for the Jellyfin server.


    The IPv6 DuckDNS domain name AAAA record must be the IPv6 Global Unicast address from the Jellyfin server. Is the Jellyfin running on a docker than the IPv6 Global Unicast address must be from the host of the Docker container. You can access Jellyfin from from the internet:

    https://duckdnsDomainName:8920/


    Another possibility and maybe much safer than a proxy or a https port forwarding is to set up a WireGuard VPN with the Fritz!Box. Here the guides from AVM to set up WireGuard with a Fritz!Box, computer, smartphone and tablet:


    WireGuard-VPN zur FRITZ!Box am Computer einrichten

    WireGuard-VPN zur FRITZ!Box am Smartphone oder Tablet einrichten

    I understand your hesitation, sticking with established products that have a proven track record definitely offers peace of mind.

    Terramaster OS relies on a Linux with its own overlay. An OMV could run on it. The F8 is a nice box, but so far there is nothing to be found that anyone has installed Linux on the F8 and it works without problems. 840 € for the F8 SSD Plus is too much for me if no other OS can be installed.


    I have found this X86-P5 2x I226-V 2.5G Development NAS Motherboard 4*M2 NVME Kit Board Intel i3-N305 N100 DDR5 2x SATA 2x HDMI2.1 for for 330 €. You may also be interested in this box.

    Maybe some of you doesn't understand correctly the problem.


    Jellyfin, Swag and my router seem correctly configured, see all screenshots/configurations from previous and current post BUT the problem is that with the iOS Jellyfin client I can login to the server using HTTP link: why?


    The screenshots looks OK. There is any security leak with the connection. I have set up a SWAG container and tested with Jellyfin. You can use the http connection in the app. The htpp will be redirected to https. In the app you see only http. Tested in a browser you can see that the http address is redirected to https.


    You are asking for a tool to check it. You can use WireShark on your device or tcpdump on the server. With this tools you capture the network traffic and check if there connection are encrypted or not.

    I understand and it makes sense for SWAG and the containers attached. I don't use SWAG. In my environment it is fine to have a network for each application. This separates the Docker containers. This can be a security benefit.


    =======================================================================================================

    FOR YOUR INFORMATION
    The pueblo.uk.to was set up only for testing purposes and is no longer reachable. The DNS record is deleted .

    have an nice day

    Soma thanks for your tips. I have found the solution. It works with pueblo.uk.to. The solution is to change the server_name in the jellyfin.subdomain.conf from jellyfin to the external URL name.



    As for the network, I never used the network_mode argument.

    I rather use the samples I posted before.

    Is there any explanation why you use your samples? At the end a new network will be create.

    In Jellyfin http is not disabled. No Subdomain given only the test Domain.

    Hear the config files and a screenshot of the Networks.


    Swag YML


    Jellyfin YML


    jellyfin.subdomain.conf

    To understand a problem, I have set up a swag container for Jellyfin. I only get the default SWAG page and not the Jellyfin website.


    Jellyfin is up and running in locale network. Port forwarding on the Router is set. Certificate exists. jellyfin.subdomain.conf is enabled. network_mode: swag-net is set in both container and Portainer network is configured. Ping from SWAG container to Jellyfin also works.


    Has anyone a tip for me?

    Maybe application show HTTP but internally the connection was redirected to HTTPS

    If you have only opened the https port on the Fritz!Box (FB). Then only https connection will be accepted on the FB WAN port, forwarded to the Swag reverse proxy, Swag to the upstream to Jellyfin on the http port. Jellyfin answer on the http request and send out http, Swag will get the http and forward https to FB, FB send https out.


    Have you configuration like the 2 screenshot? Have you set something like "Independent Port Sharing" or "Open this device completely for internet sharing via xxx (exposed host)". is your configuration for IP4, IP6 or both.


    I'm asking because I'm confused now and the router port setting and your setting in the Swag compose file are not clear to me. Can you please post the 2 screenshot from the FB for "permit Access"


    Code
                - VALIDATION=http
    ...
    ports:      - 444:443      
                #- 81:80 #optional 


    In the first post you wrote:

    Code
    On the router I have enabled port forwarding of ports 80 and 443


    Any connection from outside your network through a domain and a proxy (like swag in this case) will be encrypted. This is regardless of whether you can access that service via http on your local network.

    This is correct if you have only configured https port for forwarding. Swag is a reverse proxy and can handle http and https connection from the internet it belongs to the configuration you do.



    The 2 compose files and the config file look fine. Swag only uses the https ports 444:443 in the compose file and the upstream uses the http port 8096 to Jellyfin. With this configuration only https will run from the internet.


    What is swag doing. From the router it gets the HTTPS (444:443) request and forwarded it as a http (8096) to the Jellyfin server.

    the source is: | hostname = jellyfin.* | Port = 443 | Protocoll = HTTPS |
    the destination is: | hostname = jellyfin (localhos) | Port = 8046 | Protocoll = HTTP |

    In this case the Let’s Encrypt certificate will be managed automatically by the reverse proxy. You don’t have to interact with Jellyfin in terms of certificates at all. It will all be handled on the reverse proxy side. SWAG and Jellyfin are working correctly. In this scenario only https://jellyfin.* must be possible for connection from the internet to the Jellyfin server.


    But this don't xplain why you can connect with http://jellyfin.* Maybe something is wrong on the router or the forwarding. You wrote:

    Jellyfin standard ports 8096 and 8920 are blocked on my router and are not configured on its container (removed ports section).I don't know what router/firewall you are using, but normally ports aren't blocked, they are opened to forward port traffic to internal devices. Maybe you can show the configuration or a screenshot of the router conf.


    I don't use swag as reverse proxy with Jellyfin. I have a self signed certificate on Jellyfin and have opened only the Jellyfin https Port 8920 on the router. So that only https connection from the outside will be passed to the Jellyfin webside. Maybe this a option for you it the issue can' be fixed.