I don't know enough about the rest, but were your upstream DNS settings passed as environmental variables during the original container creation or did you fill them in after you started it? If the former, you may have a problem, if the latter I recommend you change it.
When I first set it up I changed the dns settings after the container had started.
I just did an exercise on backing up the pihole configs so now that I have a documented backup and restore process it shouldn't be a bother now.
Just checked the logs. Nothing seems to be amiss. No errors.
Although, all I did this time was stop the container, verify the volume rw status, and then start the container. When pihole "lost" its settings was when I stopped the container, shutdown omv and then restarted omv. When omv restarted the pihole container was also restarted so I'm wondering if there is some sort of "default" container startup.
For now I will monitor it though.
Thanks. When I created the stack via a compose file my volumes did not have the :rw value in it. Time to update it.
EDIT: Just checked and it was already set to writable.
Is it normal for a pihole docker container to lose some settings after it has been stopped and then started?
I recently added some fans to my case and I had to stop the pihole container before shutting down omv.
When I brought omv back online my pihole container was already started but I had to redo my upstream dns settings, my conditional forwarding and my regex lists.
Is there something I need to do to make sure my container settings are saved?
Thanks.
Your paths look different from mine.
When I ssh into my omv and do ls / I see a directory labeled srv.
ls /srv then shows me the rest of my mounted drives.
Wherever your mounted drives show that's the path you would use. According to your webui that is /dev. I have most of my drives mounted the default way (/srv) so I can't assume how your devices are mounted.
In my install:
/srv/dev-disk-by-label[disklabel]/nameOfDockerFolder
You would find this information in your disks section of the web gui.
The [disklabel] is what your disk is called and the nameofDockerFolder is whatever you want the folder to be called.
Before I installed docker I changed the docker storage path to a folder in one of my mounted drives.
The folder did not need to be a shared folder.
The docker install created the folder I specified in the location and the permissions were set.
I would say set your path first then save the setting then install docker.
And don't set it to a shared folder. Just set it to a folder in one of your mounted drives and the docker install should create it for you.
I haven't tried Yacht yet, but one of first things I'd be looking at would be easy MacVlan configuration.
Being able to assign a separate IP address to a container is a desirable feature but it seems that configuring a MacVlan interface is an exacting exercise, with pitfalls, where the config doesn't work.
I found macvlan configuration to be somewhat confusing at first. Especially when portainer was complaining about the gateway already being used.
I now have a macvlan that is used by my containers and corresponds to my LAN.
That was one of my suggestions
- Will it or can it handle docker-compose files? They are very popular with the OMV crowd and people don't always get the compose/stacks stuff. I might not have watched the video long enough if I missed it (sorry, working)
- Is there an easy way to update a container? If the restart option had another option to restart and pull new, people here would love that.
- Can the ports be auto-populated from the image with button click or something fast?
- Can the volumes be auto-populated from the image with a button click or something fast?
- Lots of people are using macvlan and it is confusing for many. Not sure how to make that faster but just a note.
- Might have missed this too but can people edit the settings of a running container and have it restart after changing the settings? Haven't needed that myself but the plugin could do it and people miss it in portainer.
Most are already being worked. macvlan is on the radar now.
1. Compose files are awesome. I found that deploying pihole, adguard and an apache test container were easier/faster with the compose files versus creating the container itself manually.
2 & 6. In portainer, I found the duplicate/edit button for the containers. I stop the container, make the changes, then click deploy container again. It gives a notice that another container with the same name exists and that portainer will replace it. I select ok. Portainer does warn that the new container may not start if the new settings are incompatible. So far I have edited containers many times with this method.
3. The ports section of portainer is a bit confusing. So a new intuitive method/process/interface would be a nice welcome.
4. I haven't tested creating volumes after the container is created. But definitely more dynamic container creation and maintenance would be a great feature from my short experience.
5. Macvlan for me proved easy to pickup though admittedly with some understanding of how portainer labels the fields and what is expected. I wish the IPAM DHCP driver was available already vs being something the user has to add themselves.
The fastest easiest way I found for the pi4 is install pios buster.
Then do the standard raspi-config setup and enable ssh.
I highly suggest setting a static IP to the pi from your dhcp server and not in the pi.
Once your pi is configured run the install script command for omv5. It will detect your pi4 and install. It will disconnect like you saw when it adds the network adaptor to omv. Simply reconnect your ssh session and verify the ip with ifconfig.
Then browse to the omv gui.
It really is a simple process on the pi4.
My pi4 that I use to test was the guinea pig when I was trying to figure how to upgrade from omv4 to omv5.
In that setup I installed pios to a 64gb usb stick and booted directly from it. Of course before that I updated the eeprom on the stable channel and enabled usb boot. I then directly installed omv5 using the script command.
I believe you should be able to install pios directly to your 120gb ssd after you update your eeprom to enable usb boot. Once it boots do the raspi-config process to setup your pios and then install omv using the script command. There should be no reason why you need to "clone" at this point.
Point taken. I have looked at newegg as well as manufacturers websites directly. I saw mini itx boards with onboard wifi (two antennas) sticking out of the io panel. I have seen boards with not enough sata ports, no m2 slots, m2 slots tight, m2 slots in a weird location (my asus prime board) and just all around anything in between.
I order from many different places but admittedly try to get as much from one source as possible due to the recent world situation that has just cobbled delivery services.
But I digress. I am not a hardware expert. I don't keep up with the trends.
If we want to talk about micro servers it would be cool if these were available for general purchase.
http://dtechlabs.com/product/m3-se-vsvr5-p/
And there are some even smaller. But of course you pay the price more for the smaller form factor.
But I do agree a mini itx build could be fun though I have found that most mini itx boards currently are geared towards gaming.
I'm still learning docker but I find portainer easy to get around.
Granted there are still some things I am learning/finding along the way.
Managing macvlans is way easier in portainer than using the docker commands. I'm not averse to ssh/command line but sometimes gui really is more efficient. I was able to create, test, delete and recreate macvlans all from portainer.
The only thing I would like to see in portainer is all the possible labels in their respective areas instead of adding one and then figuring out what label belongs where.
You're saying migrate so does that mean you are just moving files from one disk to another?
Just copying files won't work as you have just found out. Every disk would have a different uuid. What you should do is use something like clonezilla and clone the entire source drive to the destination drive. Cloning keeps the uuid intact.
I don't see why you can't just install pios directly to the ssd and then omv on top of that and be done. I have installed pios on a 64gb usb stick directly and it boots fine.
Start here for the pi eeprom
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.
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.
