Beiträge von 22/7

    Hi,


    Thank you for your reply, so how does this sound


    Freash install of Raspbian os once set up then set a static IP inside Raspbian and also onmy router, instead of installing OMV via SSH i will connect up the PI to a monitor and keyoboard and then install the code you gave?

    If you can still get into your pi now then grab the mac address for the network adaptor you are using (wifi, ethernet).


    Then set the static dhcp reservation in your dhcp server. If you do the reservation in your dhcp server there's no need to set it on the pi itself.


    Once the pi is able to pull the static IP from the dhcp server there should be no issue installing omv via ssh. If you are more comfortable with a keyboard and monitor there's nothing wrong with that either.

    Also noticed this last night my PI hangs like this

    I have to physically unplug it and then plug it back in

    I have updated all my pi4s with eeprom code and boot config options that shutdown the pi to a low power state but it still requires me to power cycle for a reboot. If yours is hanging like that I would suggest checking your firmware before proceeding with anything else.

    I would suggest setting a static IP to your raspberry pi based on its MAC address. If you can do this through your router or whatever is your dhcp server that would be the best route.


    Then redo the installation.


    I found the easiest way to install omv5 onto a pi4 is to install debian first as an sdcard flashed image (or usb or whatever boot media you choose) and then run the omv install script.


    Code
    wget -O - https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/install | sudo bash

    With a static IP address when the ssh session times out just restart it (ssh session) after 20 seconds or so and it should be done.


    I would still do the whole raspi-config steps before actuallly installing omv5.

    The problem with your idea is that the container is very, very minimal. There is no firewall and some/most of the things you might call from your script won't be installed. I think a VM would be a better fit for your firewall testing. Maybe you could install all of the packages needed to test your scripting but the VM would be easier especially if you were expecting systemd to be there.

    Thanks. As I said I am a noob to docker so I am still learning what is possible.


    What led me down this path of ideas was my pihole docker container. When I installed it as pihole:latest it automatically pulled an image running on stretch. Within the container console (via portainer > console) I was able to "upgrade" the container to buster. Only after that did I find the pihole:dev-buster image and just used that as a container.


    But I think I will toss this idea off for now. Thanks again.

    What are you trying to do with the image? An empty Debian container won't do anything. I use adb in mine.

    I guess if I need a service I can install adb. Basically I wanted to test random things under a debian system without needing to standup a full one ie bash scripting or firewall testing etc.

    I have been looking with no success.


    I wanted to see if I could setup a docker container that is basically just debian 10 and then I can play with random things inside the container.


    Is this possible?

    I ran into information from many places about how to install docker and portainer in omv for use.


    At least two instances I ran into told me I could "share" the docker folder via smb or nfs so I could see and modify the files via gui if need be.


    Well, save yourself the headaches and manage it all via ssh if you can.


    I specified my docker directory, installed docker, then portainer then could not get pihole to just start without issue. It kept complaining about various permissions (*.log permission denied, sudoers.so blah blah, etc.). It was a nightmare.


    I uninstalled portainer and docker and then deleted the original shared folder I created for docker.


    Then I specified a new directory for my docker files under the docker storage area and let docker create it for me. Then I installed portainer and proceeded to install pihole on the first try with no issues.


    I think it should be noted that it would be better to just not share your docker folder via smb/nfs like some other sources I ran into suggested.


    Also, I didn't need to change port 80 on omv or pihole. I am using my ddwrt router for my dhcp server even with pihole active. I created a macvlan with the proper IPv4 information and my pihole responds on its own IP different from my omv. So typing in omv/ in my browser takes me to the omv web gui on port 80 and typing in pihole/ takes me to my pihole web gui on port 80 as well.


    This is my first go-ahead with docker so I am glad I was able to figure it out to this point.

    So now my next question:


    I have my hc2 setup complete on my new build. Everything is as it was. I have an SMB share and an NFS share (for netbooting).


    From the instructions I have to select both disks, create another folder (the merge folder) and then set the policy.


    How does creating this new folder affect my existing locations ie the NFS share for netbooting. Are these shares still accessible the same way ie \\ipofomv\nameOfSmb\ or will it be \\ipofomv\mergeshare\nameOfSmb ?

    Fixed the tag. My bad.


    So it sounds like I need the union plugin to pool two of my drives to make a "single" volume ie my two 10Tb drives would be "combined" for 20Tb. Am I correct?


    How does this affect data in the event of a drive failure?

    My omv re-installation is coming along tackling hiccups along the way.


    I installed the union plugin in anticipation to use mergerfs.


    I also noticed another plugin that is specifically labeled mergerfs.


    What's the difference between the two?

    Are there any reasons that you can not sufficiently protect the root account with a very strong password rather than disable it altogether?

    My observations: With one strong unique password for root, and another strong unique password for the sudo user the omv install script still managed to drop into root level privilege (actual root account) and run the commands without prompting for the password. The omv install script couldn't have known the root password either so the fact that just having the root account enabled was enough for the script to gain that access seems to imply a security hole. But that's just my opinion.

    I installed a vanilla debian os. Then I locked down the root accounts after creating an account with sudo permissions. Then I proceeded to install omv onto buster and that's when it complained about the root account not being available.


    So would there be any way to install and run omv without the explicit need for root but maybe by sudo permissions given to whatever userid the omv framework uses?

    What is this "omv account " you refer to?

    You got me. I just thought when I used sudo to run commands it was based off my user account sudo permissions. Then when omv commands were being run that is was using some sort of "omv account" and why it couldn't run elevated privilege commands.

    I would expect endless problems with this. Can you explain your use case that requires disabling the root user account?

    Since this is a more powerful hardware rig compared to the hc2 I have some plans for the box to include being a vpn server in docker. To vpn I would need to expose the rig itself to the outside world unlike the hc2 which was all local except for reaching out for updates. I am running it headless and accessed only through ssh so essentially just locking down debian itself.


    Is it possible to add the omv account to the sudo group?

    I built a new nas box to replace my hc2 and immediately found out that despite some posts saying that omv can be moved to new hardware without issue that was not my case.


    I cloned my hc2 sdcard to my new ssd and it refused to boot whether bios, efi, csm support etc. I cloned multiple times with multiple programs and none booted. Chalk it up to moving from a 32bit arm to a 64bit x86.


    Anyways, I am now down the long path of manually installing everything. I installed buster 64 bit uefi already and did the usual hardening regarding the root account and locking down all avenues of root.


    When I attempted to install omv it complained about root account not available (because I disabled it) and to check that the sbin/nologin is configured correctly. I am running all commands with sudo with no issues. The only way omv would install is if I enabled the root account in etc/passwd.


    Now that omv is installed I disabled the root account again. Will future omv related commands or upgrades be affected by the root account being completely disabled? I do find it interesting that even with sudo the omv install process required dropping directly into the root account.

    If I need extra drives and I don't feel like changing the board right away I may just use this

    https://www.amazon.com/dp/B00W…sc=1&ref_=lv_ov_lig_dp_it


    At that point if I need more than 4 data drives (which I don't think I am close to yet) then a new board will be done.


    I can always test the vm performance and if it doesn't pan out then it won't be a huge loss. Alot of what I am trying to consolidate right now is linux headless stuff so docker should fill most of my immediate needs.

    Well, if your needs do change, I hope you can reuse the CPU, and memory in a more capable board.

    I am prepared to move the cpu to a thick mITX board if that should happen but I don't anticipate it to be anytime soon anyways. The h310t also has an m.2 e key port for pcie expansion if I need it but again at that point I may as well change boards.

    Am I reading that right - only 2 SATA ports and no expansion slot?

    Correct. Currently I only have 1 10tb drive in my hc2 and another 10tb on standby. I am not yet at the point of needing more than 2 drives. I don't hoard as much data as most do (yet) so this is everything I need at this point in time.