Beiträge von igrnt

Thanks for testing and the logs - I will check it out and get back to you.

Init script is (in your case) /etc/init.d/spindowncheck - what's in that file? And did you 'register' it? (probably via insserv)

omv-engined -df us great for debugging the RPC. Developer console in, e.g. Chrome, can help with syntax errors in WebGUI JS files.

About LUKS
LUKS is the standard for Linux hard disk encryption. By providing a standard on-disk-format, it does not only facilitate compatibility among distributions, but also provides secure management of multiple user passwords.In contrast to existing solution, LUKS stores all setup necessary setup information in the partition header,enabling the user to transport or migrate his data seamlessly.
See also: https://gitlab.com/cryptsetup/cryptsetup

About the plugin
This plugin provides for basic manipulation of LUKS-encrypted devices in OpenMediaVault; encrypted devices can be created, destroyed, opened (unlocked/mounted) and closed (locked/unmounted). Keys (regular passphrase and key files) can be added, changed, and removed. The header (which contains the master key and they keys (passphrases) used to unlock it) can be backed up and restored.
The plugin is designed to work with bare disks, the workflow being that you encrypt a raw disk (e.g. /dev/sdb, though you could also encrypt a RAID device, LVM logical volume, or existing partition). When the encrypted disk is unlocked, a device mapper device is created that provides access to the decrypted disk (they are currently named by appending '-crypt' to the devicename, e.g. /dev/mapper/sdb-crypt). Filesystems can then be created on top of this and used throughout the rest of OMV as normal.

How to install
To install the plugin, first install the OMV Extras plugin, then you can install openmediavault-luksecnryption from the Plugins section of the WebGUI. After installation, a new section, 'Encryption' appears under Storage (after Physical Disks and S.M.A.R.T.).

Usage notes
Devices must be unlocked via the WebGUI (select the device, click the 'Unlock' button and enter the passphrase), this means that they will (currently) remain locked at boot until manually unlocked. Services such as SMB/CIFS using shared folders on the encrypted disk will not work properly and may give errors about missing filesystems until the disk is unlocked, but will usually work fine after unlocking without any further need to restart.
Adding and removing keys
You can have up to 8 keys (passphrases) per device. Take care when removing removing passphrases - the GUI will check before proceeding, but it will allow you to remove the last key. If you do this, the device will be rendered useless as you will be unable to unlock it.
Which leads on to...
Backing up and restoring the header
The header on a LUKS-encrypted device contains details of the encryption method and cipher, and also the master key needed for en-/decryption, itself encrypted by up to 8 passphrases, stored in key slots 0-7. It is advisable to make a backup of the header whenever you create an encrypted device or add, remove or change any of the passphrases. If the header or any of the key slots become corrupt (or you accidentally remove all the keys! - see above), you can restore the header from a backup, which will restore the passphrases as they were in the backup.

Future plans
Support for automatic unlocking at boot is planned.

Dos and Don'ts
Do...

• Make a backup of the header when you create an encrypted device and every time you add/change/remove keys. Store it somewhere else - not on the encrypted drive!
• Consider adding multiple keys, i.e. one that you use regularly especially if you find yourself changing it often, and one to keep in 'escrow' as an emergency
• Take care accessing the WebGUI over unencrypted channels (plain HTTP), especially if operating remotely - the keys are transmitted in the clear over the network
• Understand the limitations of encryption (see About encryption, below)

Don't...

• Restore the same header to multiple devices - it creates a point of single weakness in terms of encryption, and might cause problems in the future for automatic unlocking at boot
• Remove all the keys from a device (unless you know what you're doing) - it renders the device useless as you can't unlock it again
• Overwrite the header of a device (e.g. with disk partitioning software) - whilst you can restore the header from a backup, if you write further into the disk than the end of the header (2 MiB), you will be overwriting your actual data

About encryption (caveats)
The most useful aspect of whole disk encryption in this way is that you can dispose of the disks without needing to wipe them - just destroy the key and the data is irretrievable.
It can also protect against data access in the case of theft of your NAS - the power will usually necessarily be cut to a stolen device, locking the disks. Except, of course if you are automatically unlocking the disks at boot time (not currently an option in the plugin), using a key that is necessarily stored somewhere accessible (e.g. on the OS drive).
Note that even if you don't do this, every time you upload a key file via the WebGUI, it is written to disk (/tmp) temporarily. A determined attacker might be able to recover the contents of the key file even after it has been deleted. The plugin attempts to ameliorate against this by securely deleting (shredding) uploaded key files, but even this is not 100% foolproof. You can take further steps by moving /tmp to a tmpfs in RAM, rather than on-disk, or also by encrypting the OS drive. Both these things are beyond the scope of this guide. Of course, these are corner cases - whole disk encryption is reliably secure for most cases.
Of course, encryption cannot protect against an attacker who has access to your live system - the data on the disks are necessarily decrypted when the system is running!

Support
Please report issues on GitHub (https://github.com/OpenMediaVa…ult-luksencryption/issues), or use this thread for discussion/support/problems with the plugin.

no-start flag is good to know, I have added it to my mpd plugin too now.

If it's just for maintaining a bunch of repos, pushing stuff to github, bintray etc. then I probably don't need to use it. I thought it might add some debugging output or something to OMV, but I managed to develop my plugin without it quite easily so I guess I won't really worry about proxy-ing it up.

I installed a ton of plugins in my developmental OMV install in a virtual machine, and have noticed that several of them then show up as the services running when the interface reloads, despite the plugin not being enabled via the OMV interface. This is likely due to the postinst script not disabling the service in the main package - Debian services otherwise start as soon as they are installed, but a good OMV plugin should override this until the user explicitly enables the service.

I thought it might be useful to keep a list of this, so the plugins I have noticed showing this behaviour are:

• Calibre
• Mcmyadmin
• OpenVPN
• PlexMediaServer
• Shairport
• PXE

Also, I haven't fully investigated this, and it might just of course be down to a broken plugin that reports it is running when it isn't.

Great, thanks for the PM. Forking my repo is fine. I have just updated it as there was a small error in the RPC module that caused the service running check to fail (see https://github.com/imgrant/openmediavault-mpd/releases, v1.0.1 deb uploaded too).

I started with the openmediavault-skeleton repo and copied from other plugins. I downloaded the plugin-utilities and the -developer plugin, which I installed in my OMV VM but have not really worked out what it's for yet. Hoping there is more to learn in the dev forum!
My VM is on a machine that is behind a HTTP proxy, which causes a load of headaches, but in particular for the developer plugin, it gives some error about connecting:

Error #4001:
exception 'OMVException' with message 'Error: "connect() timed out!" - Code: 28' in /usr/share/openmediavault/engined/rpc/developer.inc:103
Stack trace:
#0 /usr/share/openmediavault/engined/rpc/developer.inc(1113): OMVRpcServiceDeveloper->_doApiCall('https://api.bin...')
#1 /usr/share/openmediavault/engined/rpc/developer.inc(834): OMVRpcServiceDeveloper->syncBintrayData(Array, Array)
#2 [internal function]: OMVRpcServiceDeveloper->getBintrayRepos(Array, Array)
#3 /usr/share/php/openmediavault/rpcservice.inc(125): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc.inc(79): OMVRpcServiceAbstract->callMethod('getBintrayRepos', Array, Array)
#5 /usr/sbin/omv-engined(500): OMVRpc::exec('Developer', 'getBintrayRepos', Array, Array, 1)

How can I get it to use a proxy?

About MPD
Music Player Daemon (MPD) is a server that allows remote access for playing audio files (Ogg-Vorbis, FLAC, MP3, Wave, and AIFF), streams (Ogg-Vorbis, MP3) and managing playlists. Gapless playback, buffered output, and crossfading support is also included. The design focus is on integrating a computer into a stereo system that provides control for music playback over a TCP/IP network. The goals are to be easy to install and use, to have minimal resource requirements (it has been reported to run fine on a Pentium 75), and to remain stable and flexible. Control is via client applications (such as the command line utility, mpc).

About the plugin
Supports basic configuration of most common options, including setting shared folders for the music and playlist directories (although if just used for streaming, MPD can function without these options configured). Multiple audio outputs are supported, but configuration options specific to plugins must be entered manually as 'extra options'. For example, configuring the device or mixer control for an ALSA output. However, left blank, or even without any outputs configured, MPD attempts to pick a sensible default (i.e. the first ALSA device on Linux), so the plugin should work fine out of the box for most typical setups.
Upgrading MPD to a later version than that installed by default with Debian Wheezy (0.16.7), e.g. version 0.17.6 from the wheezy-backports repository (Debian Jessie, OMV 3.0 already has a later version, of course), is recommended (most notably to support the restore_paused configuration option).

How to install
To install the plugin, first install the OMV Extras plugin, then you can install openmediavault-mpd from the Plugins section of the WebGUI.

Support
Please either report issues on GitHub (https://github.com/OpenMediaVa…openmediavault-mpd/issues) or use this thread for discussion/support/problems with the plugin.

I [still] have this problem too, exactly the same, duplicate cron-apt update ready emails at 4 am and 7.35 am.

As far as I can see, the 4 am cron-apt is run because /etc/cron.d/cron-apt is configured so:

#
# Regular cron jobs for the cron-apt package
#
# Every night at 4 o'clock.
0 4     * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 *   * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 * * * *   root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

... and the 7.35 am job because of /etc/cron.daily/openmediavault-cron-apt: test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt

These files are the same on an OMV install that has been upgraded from 1.9 (I think) to 2.1 and has other packages and stuff, but also on a fresh install of 2.1 I did in a VM to test it.
The file /etc/cron.daily/openmediavault-cron-apt contains the following note:

# NOTE:
# If the machine does not run 24/7 it might happen that cron-apt is not
# executed. Because anacron does not execute cron jobs defined in /etc/cron.d
# (where the default cron-apt cron job file is located) this script ensures
# that cron-apt is executed at least once a day.

So, if the machine does run 24/7, it follows that both the default cron-apt job in cron.d and the omv job in cron.daily are run. I would therefore suggest that the default cron-apt is disabled.

Similar to other threads for transmission, I am getting error mails with the message:

invoke-rc.d: initscript rsyslog, action "reload" failed.
error: error running shared postrotate script for '/var/log/autoshutdown.log

The error is due to the init script for rsyslog no longer supporting the 'reload' action. I changed it (in /etc/logrotate.conf/autoshutdown) to use 'rotate' instead which I think was added for this purpose. I tried to file a bug in Mantis for this, but I got an error message about invalidating my session, so I am posting here.