Posts by Pollux

    Learned some new things today :thumbsup:
    - created a github account
    - did a fork
    - git clone
    - git commit (twice since I missed something out in the first one)
    - git push
    - git pull


    Hopefully I did everything right ... keep in mind that I am no developper and never used git before today.

    Well, I had a few hours to waste so I tweaked OpenVPN plugin files to achieve the following:


    - Added 'Default Gateway' flag in OpenVPN settings

    If enabled, this directive will configure all clients to redirect their default network gateway through the VPN (push "redirect-gateway def1 bypass-dhcp"). If disabled, a static route to the private subnet is configured on all clients (push "route <subnet> <mask>").


    Note that I'm not a developper and it took me ages to make the openvpn mkconf script to get the subnet part. There might be a better way to do it, but at least it is working.



    - Added an OpenVPN status tab


    OpenVPN tab in Diagnostics > Services shows a cat /etc/openvpn/openvpn-status.log and a cat /etc/openvpn/ipp.txt



    - Fixed log timestamp


    Now time is displayed correctly in the OpenVPN logs from Diagnostics > System Logs



    Note that when log are higher than normal, it seems to break again the timestamp. I didn't fix that.


    - Other update not 'visible'


    Generated config file uncomment the following:
    user nobody
    group nogroup


    It seems more secure to me as it will reduce the OpenVPN daemon's privileges after initialization.


    __________________________________________


    For those interested, I've attached the tweaked files.


    tweaked_openvpn.zip


    To install, first make a backup of original files:

    Code
    cd /
    tar pzvcf omv-openvpn-backup.tgz /var/www/openmediavault/js/omv/module/admin/service/openvpn/Settings.js /usr/share/openmediavault/engined/rpc/openvpn.inc /usr/share/openmediavault/engined/module/openvpn.inc /usr/share/openmediavault/mkconf/openvpn


    To install tweaked files, put first omv-openvpn-tweak.tgz in / then untar and restart omv-engined:

    Code
    cd /
    tar pzvxf omv-openvpn-tweak.tgz
    service openmediavault-engined restart


    Also refresh webgui page.


    To uninstall tweaked files and restore original files:

    Code
    rm /var/www/openmediavault/js/omv/module/admin/diagnostic/service/plugin/OpenVPN.js
    cd /
    tar pzvxf omv-openvpn-backup.tgz
    service openmediavault-engined restart


    Also refresh webgui page.


    If OpenMediaVault Plugin Developers want to include any of those changes in the official OpenVPN plugin, they are welcome to do so.

    You should be able to grow the raid by adding the disk in the webgui, but you won't be able to resize the Physical Volume since the LVM plugin only allows creation/deletion of a PV. For that part you will have to do it from command line. The rest (extend LV then resize FS) should be possible from webgui.

    Well, it's kind of hard to answer with the scarce details you've provided ...


    Providing the output of the following interrogation commands would help:


    Code
    df -h
    mdadm --detail /dev/md*
    cat /proc/mdstat
    pvdisplay
    vgdisplay
    lvdisplay


    But assuming you have an ext4 filesystem on top of LVM which is itself on top of a mdadm array of 3 drives in raid5, it would look something like that:


    Code
    mdadm --grow /dev/mdX --raid-devices=4 --add /dev/sdY
    pvresize /dev/mdX
    vgdisplay
    lvextend -l +100%FREE <logical vol path>
    resize2fs <logical vol path>


    :!: Warning: after issuing the mdadm grow command, you should wait for the raid array to complete rebuilding before extending the lvm and filesystem. It could take several hours or a couple of days depending on your array size.


    I strongly advise, beside having a backup, that you test this in a virtual machine to avoid any data loss. I won't be held responsible if you loose any data.

    Thank you for your reply. You were spot on. It looks like the calculation has indeed changed.


    BTW I did not need to reboot for the changes to be seen (only refresh graphs).


    I've set back the value to the default 5%. I'm not sure this is really needed on a data disk to avoid fragmentation (contrary to OS filesystem).

    Hello,


    I'm glad to see that the openvpn plugin made it back in OMV 1.0 release (I stayed on OMV 0.4 for quite some time because of that). Many thanks to the developpers for their work.


    Default configuration works like a charm but I think there is some room for improvement:


    On routing aspects, by default the script sets for the client to route everything via the VPN (push "redirect-gateway def1 bypass-dhcp"). It would be great to be able to change this behaviour to only route the private subnet toward the VPN (push "route 192.168.x.0 255.255.255.0") while the rest is still routed to the initial default gateway of the client. A flag 'Default route to VPN' in the VPN network section of the OpenVPN plugin webgui which can be enabled/disabled would do the trick.


    When somenone is connected, there is no status tab in the webgui showing connected clients. It would be nice to have an OpenVPN tab in Diagnostics > Services displaying a cat /etc/openvpn/openvpn-status.log to show connected users.


    I've also noticed that the OpenVPN daemon's privileges is set to root. Is there a reason for not using the following options to reduce the OpenVPN daemon's privileges after initialization?
    user nobody
    group nogroup


    Regarding logging, the date format seems to be different than other logs, therefore, when reading OpenVPN logs from Diagnostics > System Logs webgui, the date wrongly shows UNIX EPOC date (01 Jan 1970). I don't know if this is something that can be fixed directly on OpenVPN level or if a workaround can be implemented on OMV to be able to display different kind of date format.


    Thanks.

    Hello,


    I did a reinstall from scratch to go from omv 0.5 to 1.0. I reconfigured everything, no issues so far, it went quite smoothly.


    I wanted to keep RRD records. I managed to backup then restore the RRD records but had to do some manipulation with the df RRD records because the format changed between 0.5 and 1.0.


    For some reason, after I restored my RRD records, the free space for my data volume is not identical to previous omv version (while used space remains the same). See screenshot below to illustrate:



    I doubt this is an RRD issue as I did not change any data, I'm thinking more about something like space reservation which used some free space.


    Does anyone has some explaination to this?


    Thanks.

    It seems the recover button not only adds the disk, but also launches the command 'omv-mkconf mdadm'. While the raid is recovering, the newly added disk is flagged as 'spare', you can check it with 'mdadm --detail /dev/md127' and 'mdadm -Es' commands. Therefore that information is written in the /etc/mdadm/mdadm.conf file by the 'omv-mkconf mdadm' command.


    If you run the command 'omv-mkconf mdadm' AFTER the raid has finished to recover, it will remove the spare parameter in the /etc/mdadm/mdadm.conf file.


    Related bugs:
    http://bugtracker.openmediavault.org/view.php?id=734
    http://bugtracker.openmediavault.org/view.php?id=747

    Did you see anything suspicious in proftpd.log and in tls.log (both are in /var/log/proftpd/)?


    Also, checking the 'No session reuse required' parameter may help solve your problem.

    How to contribute to wiki? Looks like wiki and forum don't share the same user database and I can't find the page to create a wiki user.

    wow, did I read well? You are trying to expand a raid 0 but don't have any backup. It seems you like to live dangerously: one drive dies and so does the whole array... The odd of this happening with 3 drives being higher than with 2 drives.


    I don't know if mdadm allows to grow a raid 0 (I thought you wanted to grow a 2 drives raid 1 array to a 3 drives raid 5 array, which is possible with mdadm), but did you try the following command:
    mdadm --grow /dev/md127 --raid-devices=3 --add /dev/sde


    By the way, try this first in a VM as I won't be held responsible if it crashes your array. You've been warned.

    It looks fine. You did not answer one of my previous question: is the 'resize' button grayed out in the 'Filesystems' panel?


    Also what is the ouput of the following command:

    Code
    df -lh


    If the size of the filesystem does not match the array size, you can try to grow it with the following command (assuming the filesystem is EXT)

    Code
    resize2fs /dev/md0


    But you should be able to do it with the 'resize' button in the 'Filesystems' panel.