Posts by christiscarborough

This script was just what I needed, thanks. Have now purged the old and somewhat unreliable letsencrypt plugin from my system and moved to using dehydrated for certificate requests.

Thanks for this. That does exactly what I want and will ensure my config changes don't get overwritten (so long as /etc/default/openmediavault is safe from being overwritten).

It would be added to ups.conf rather than to upsd.conf.

My UPS (a Powerwalker VI2200LCD) requires that a parameter "MAXAGE 100" be set in upsd.conf. Is there any way that a feature could be added to the NUT plugin to allow tweaking the contents of upsd.conf, please?

I may be going for some kind of replying to my own posts record here. Working on the basis of ellnic's suggestion, I stopped nginx and all of the services using my ZFS filesystems, ran a "zpool export" manually and then rebooted the machine. This seems to have fixed the problem for now, although I still don't have a mntent for the root of the pool.

(Speculation: I wonder if the current tmpfile bug is causing mntents to generate spurious error conditions and then OMV is aggressively removing these filesystems as "non-existent".)

OK, a second filesystem has now gone missing, one of the older ones. Recreating the mntent entries by hand using the mntent entries from the filesystems just results in the recreated entries being deleted. Help, please!

OK, OMV just lost track of the re-created ZFS filesystem that I made to get around this problem. This filesystem is mounted at boot time, so I cannot understand why this is happening. This is now a serious problem for me, as my owncloud installation is dependent on that partition existing. Again, it looks as though this is as a result of OMV deleting the appropriate mntent entry from config.xml. Why this filesystem and not the others? No idea. The only difference is that the other filesystems have been around for several years, but this one was created within the last month.

Are there any plans to include in the Network UPS Tools plugin the option to shut down the machine from a remote UPS (i.e. a slave configuration). As it currently stands, it would appear difficult to configure NUT to do this manually without installing it independently of OMV, because in order to enable NUT in the OMV interface, a working local UPS configuration needs to be supplied.

As it happens I have pools I unmount and mount while running to back up my main storage (which is mounted at boot time through OMV). Fortunately I handle all that outside of the OMV interface.

What's still a mystery to me is (a) how my root storage zpool (mounted at boot) lost its mntent (b) why I can't for the life of me get OMV to re-recognise it. As a practical problem this is a non-issue for me, as I only ever use filesystems off the root pool so I don't need to access it from the OMV interface, but it concerns me that I may in future "lose" e.g. the owncloud filesystem, which I absolutely cannot delete and recreate or manage without.

I should note also that while it's possible that an export/import/reboot as above might fix the issues, I'd have to remove and later recreate significant amounts of service settings in order to get to the point where I could export my NAS storage pool, so that's a far from ideal solution.

Quote from tux1337

I know you solved it with recreation of the filesystem, but maybe it helps others:

Should be enough to go to the Filesystem Section in the webinterface, and click to "mount". The ZFS filesystem is already mounted, but in my case this generates the entry in the XML.

Sadly, the "mount" button in the filesystems tab seems to be greyed out, so this may not work for everyone.

I can confirm that when I add in an entry for a "vanished" drive, not only do associated shares continue to fail to show a mount point, but the mntent disk entry is deleted from config.xml post boot, presumably by the mechanism above. Could it be that the ZFS plugin expects some magic in the mntent UUID entries?

Using the old UUID did not work. As there wasn't much on the relevant filesystem, I ended up destroying it on the command line then re-creating it in the GUI. My root zpool still has no UUID, but since I don't stick anything in the root except file systems, that's not so much of an issue. Thanks to everyone who helped out.

This is related to my difficulties with the recent failed backport kernel upgrade, but posting here also, as this is a more general question.

I have two zfs filesystems which show up in my list of file systems, but do not have usage information available. This appears to be because they lack associated mntent entries in config.xml. I would like to create mntent entries manually for them, but I do not know how to acquire the correct UUID for the filesystems. (I tried using a UUID that was valid before the zfs kernel module rebuild that was necessary, but this did not work, and OMV removed it from my config.xml, so it must be that the OMV UUID is created based upon an external filesystem identifier.)

How, given a mounted ZFS filesystem, do I generate a UUID for putting in a config.xml mntent entry which OMV will recognise as being connected to that file system? Thanks

OK, so copying the relevant UUID from the mntent section to the share section does the trick BUT ...

For some reason one of my ZFS filessystems has no mntent entry. It cannot be selected from the filesystems dropdown.

Would it be safe to create an mntent entry for it using the old mntent entry? Is there a way to generate a new UUID to put in an mntent entry?

Thanks for this. I will give it a go and let you know how I get on.

I tried to update the backport kernel the other day, which did not work, so I reverted to 4.14. I had to use dpkg-reconfigure to rebuild the ZFS modules. My ZFS volumes are being mounted again now, but OMV seems to have lost track of them. If I try to edit my shares, I get:

Failed to execute XPath query '//system/fstab/mntent[uuid='0a27a87b-80c8-4b53-b701-1664a7189ed7']'.

I assume that the UUID of my ZFS drives has changed due to all of the changes. How do I get OMV to use the correct, current UUID (and how do I find out what the correct UUID is)? Thanks.

I hadn't appreciated that this requires update of DNS *every time* a new certificate is generated, which I agree makes it more challenging. People have worked around this using manual hooks - see https://serverfault.com/questi…m_campaign=google_rich_qa.

I think this means that if you used a UI dropdown to toggle authentication type, and allowed users to enter their own manual hook script in a similar way to how the nginx plugin allows you to enter web server config, then it might be possible to implement simply by calling letsencrypt with the appropriate options. (Presumably you'd need to run any such script as an untrusted user.) There's a whole bunch of hook scripts available at:

https://github.com/lukas2511/d…Examples-for-DNS-01-hooks

Thanks for considering anyway. I understand it won't be possible to replicate the entire certbot command line in the UI, and it may well be that there are security implications to using custom hooks via the GUI, but it would definitely my my and my partner's life easier if this were possible.

The facility to authenticate via DNS exists in letsencrypt. The omv-letsencrypt plugin relies on the older method of placing a token file in the webroot of the server on port 80. There is no option to use DNS authentication in the plugin. This is why I would like the developer of omv-letsencrypt to add this as an option. Obviously one or both of us could manually configure letsencrypt to use DNS authentication, but that would not allow for automatic seemless updates of our OMV SSL certificates. Hopefully all is now clear.

Quote from ryecoaaron

There is a letsencrypt wildcard cert docker image available now that should solve just about everyone's need for an alternative method.

I don't see how a docker image could allow for automatic certificate update on two separate OMV servers behind the same NAT router, but thank you for the suggestion. I really think that the only way things will work for our particular setup is if the OMV-letsencrypt plugin gets support for DNS authentication.

Any chance of getting this plugin to use DNS as an alternative to webroot validation. My partner and I both have OMV servers, and they can't both sit on port 80, but we do both have our own domains, so we could both have LetsEncrypt SSL certificates if we could update them via DNS token rather than webroot. (Also, I'd prefer not to have the admin console accessible over raw http if I can avoid it.)