Re: [linux-lvm] Possible Bug vgrename
On Mon, Jun 21, 2021 at 02:48:23PM -0500, David Teigland wrote: > On Mon, Jun 21, 2021 at 11:32:12AM -0700, N wrote: > > Is there a way to temporarily rename (without actually renaming) the volume > > groups (i.e. like setting a mask for the volume group names), or is there a > > way to force vgrename to actually make the change even if there is an > > existing conflict (preferably without a reboot)? > You can set a device filter the vgrename command so it only sees the > devices with the VG you want to change, and won't see devices with the > duplicate name. > vgrename --config 'devices/filter=["a|/dev/...|", "r|.|"]' vg1 vg2 And look at how the 'vgimportclone' shell script uses filters and other techniques to set up a segregated environment in which to modify a VG that isn't being used on the machine. As extra protection sometimes, you can also tell a command not to talk to the kernel dm subsystem by using '--driverloaded n'. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Mirror allocation policy
On Wed, Jan 06, 2021 at 09:36:39AM -0500, Phillip Susi wrote: > Based on the number of extents it said it was looking for, I didn't > think it was the log that it couldn't place. It was looking for what it calls 'parallel' extents i.e. extents not on the same device as the ones belonging to the existing LV being converted, and, at first sight, it wasn't giving you the option of overriding that in respect of the log. Clearly the code could be improved, but it's a very much a niche case, well outside the normal way it's expected to be used. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Mirror allocation policy
> #libdm-config.c:1061 Setting > allocation/mirror_logs_require_separate_pvs to 0 So despite that, it's not letting you have the 'anywhere' for the log part of the allocation. However, for what you are doing, maybe you don't need an on-disk mirror log or can temporarily borrow a little space (add small temporary loopback PV to the VG?) for it? > #metadata/lv_manip.c:2704 Still need 7681 total extents from > 370508 remaining (0 positional slots): > #metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas > of 7680 extents each > #metadata/lv_manip.c:2711 1 metadata area of 1 extents each > #metadata/lv_manip.c:2535 Not using free space on existing > parallel PV /dev/md1. > #metadata/lv_manip.c:3220 Insufficient suitable allocatable extents > for logical volume : 7681 more required Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Mirror allocation policy
On Tue, Jan 05, 2021 at 02:31:00PM -0500, Phillip Susi wrote: > How can I forge it to make the mirror on a single pv? If --alloc anywhere isn't doing the trick, you'll need to dig into the - output to try to understand why. There might be a config option setting getting in the way disabling the choice you want it to make, or if it's an algorithmic issue you might try to coax it to do the right thing by removing whatever choice it has in the allocation by specifying the actual pv:extent ranges it must use on the command line. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] storage-logger: Recording changes to the udev database
On Fri, Mar 27, 2020 at 03:50:06PM -0400, Brian McCullough wrote: > In your instructions, you say to put the "working" script in /usr/sbin, > while in the udev rule, it is in /sbin/ In Fedora they are the same. > I tried adding and removing a USB-connected drive, but did not see any > response in the journal. Should I have seen something, or are those not > seen? You should test the script in isolation in case there are any other differences on Debian. Change the top line to '...bash -x' so you can watch it, set some environment variables (like ACTION=add) and run it directly. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[linux-lvm] storage-logger: Recording changes to the udev database
I'm experimenting with ways of recording changes to the udev database so you can look back at the history of the storage stack on a particular machine. This is still a work-in-progress, but it's reached a point where I'd like more people to try it out. I've written a shell script that records data related to storage uevents in the system journal and a perl script that helps you to interrogate this data later to create a representation of the storage components. If you're interested, please try this out and let me know if you think pursing this approach further would lead to something that you would use and distributions should ship. Source code: https://github.com/lvmteam/storage-logger Fedora builds: https://copr.fedorainfracloud.org/coprs/agk/storage-logger/build/1320735/ Presentation: https://fosdem.org/2020/schedule/event/storage_logger/ Storage-logger == The storage-logger project maintains a record of the storage configuration of a linux system as it changes over time. The idea is to provide a quick way to check the state of a system at times in the past. Logging === The initial logging implementation is triggered by storage uevents and consists of two components: 1. A new udev rule file, 99-zzz-storage-logger.rules, which runs after all the other rules have run and invokes: 2. A script, udev_storage_logger.sh, that captures relevant information about devices that changed and stores it in the system journal. The effect is to log relevant uevents plus some supplementary information. It does not yet handle filesystem-related events. Reporting = Two methods to query the data are offered: 1. journalctl Reports the raw data using simple filtering. Data is tagged with the identifier UDEVLOG and retrievable as key-value pairs. All the captured data: journalctl -t UDEVLOG --output verbose or as JSON: journalctl -t UDEVLOG --output json Between a time range: --since '-MM-DD HH:MM:SS' --until '-MM-DD HH:MM:SS' Other filtering features are described in the man page. 2. lsblkj This wrapper creates a dummy system environment that "looks like" the system did at a specified earlier time and then runs lsblk against it. It accepts --since and --until arguments to pass to journalctl to select the desired data, and passes other arguments controlling the output format to the real lsblk. Use --verbose to watch it setting up the temporary environment . Use --dry-run to see what it would do without actually doing it. Use --git to create a git repository recording the changes over time. Alasdair -- a...@redhat.com ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] devices/dir configuration option in /etc/lvm/lvm.conf can be edited?
On Mon, Oct 14, 2019 at 10:52:02AM +, Gang He wrote: > That means we should tell the user, you should not edit this option (dir = > "/dev") in the lvm.conf, right? The existing comment is incomplete and should be updated to mention the other effects. The option pre-dates udev and so the "newer" interlocking there ought to be mentioned. The description of 'advanced' could also be updated to explain that that means you should not change it unless you know exactly what you are doing! The option exists to simplify some development, test and support scenarios where you want to have two or more distinct userspace LVM instances running on a single machine. For example, to try to reproduce a certain type of user-reported bug you might set up a temporary /dev in a non-default location with contents that match that user's system and point the tools at that using this option. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] lvcreate from a setuid-root binary
On Mon, Nov 19, 2018 at 09:55:07AM +0100, Christoph Pleger wrote: > My program calls getpwuid() with the real user id of the calling user > and then compares this user's name with the name of the one and only > user who is allowed to continue program execution. Do you think that > this can be circumvented? I'll just repeat - don't write your own setuid programs if you care about security. Here's an old paper that lists some (and certainly not all!) of the things people who do write them have to understand: http://man7.org/conf/lca2010/writing_secure_privileged_programs.pdf It only takes one mistake or one thing you didn't know about or understand properly to make your system insecure. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] lvcreate from a setuid-root binary
On Fri, Nov 16, 2018 at 02:43:10PM +0100, Christoph Pleger wrote: > I get security by checking the real user id at the beginning of the > program and aborting the program if that uid does not belong to the only > user who is allowed to run the program. Sounds familiar. Shall I tell you one of those stories? I used a system where the sysadmin was worried that letting people run the setuid 'su' binary was too dangerous, so he wrote a wrapper around it to "improve" security. The wrapper checked you were in the admin group before letting you run the real 'su'. Of course anyone who understood how setuid works better than he did could now use the wrapper in numerous different ways to become root directly without a password. If you care about security find another solution that doesn't involve writing your own privileged code to be run under the control of an unprivileged user. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] lvcreate from a setuid-root binary
On Thu, Nov 15, 2018 at 05:39:56PM +0100, Christoph Pleger wrote: > I am calling lvcreate from a setuid-binary, which internally calls Let's stop there. The fact you're asking a question about setuid suggests you don't understand enough to be able to use it safely. Seriously, never use setuid for anything until you have a thorough understanding of its internals (userspace and kernel) and ld-linux, capabilities, process contexts, acls, selinux etc. It's just too easy to make your system insecure because of something you didn't even realise you had to consider! (I could tell you some funny stories...) Go back to the beginning and describe the original problem you are trying to solve and the constraints you have and ask for advice about ways to achieve it. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] unable to exclude LVs using global_filter
Also there is no special handling for |.*| - a match against it gets treated as a positive deliberate match, just the same way as a match against |/dev/sda2|. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] unable to exclude LVs using global_filter
The key concept to grasp is that LVM works with devices (i.e. major number + minor number pairs) rather than filesystem paths and it makes a single "use or ignore" decision for each device (not for each path). One device might be reachable through more than one filesystem path that lvm has been configured to check and, if so, all the paths are checked against the filter independently and the results feed into that single decision according to the rules described. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] lvm filter not ignoring block device
On Mon, Dec 18, 2017 at 04:48:19PM +, Thanos Makatos wrote: > filter = [ "r|/dev/mapper/foo7|" ] Try setting global_filter. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] lvm operation hangs at semop()
Most likely your lvm and udev rules are incompatible. As I said before, if you're using a standard distro, you must find out what patches and config options were used to build the installed packages and use the same ones when you configure your own lvm build. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] LVM Merge
On Sun, May 15, 2016 at 04:35:44AM +, Tom Jay wrote: > I've posted a question to the debian-user mailing list, but am yet to receive > a response. > I am running Debian 7.9 64-bit with kernel version 3.2.0 and would like to > use the 'lvconvert --merge' feature, but do not have 'snapshot-merge' support > in the kernel. Does anyone have any idea how to enable this? > The original post is here: > https://lists.debian.org/debian-user/2016/05/msg00496.html. So you don't have any snapshot support in your running kernel. But your kernel is modular, and if you attempt a snapshot operation, lvm2 will try to load the snapshot module if it is available. To try this manually, do 'modprobe dm-snapshot' (see 'man modprobe') then retry 'dmsetup targets'. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Shrinking LVM partition at beginning
On Sat, Apr 09, 2016 at 07:52:07PM +0200, Zdenek Kabelac wrote: > Unsupported The process could easily be automated, but there just isn't enough demand to justify spending the time writing and testing code for it. An expert would also find it pretty easy to test each step as they proceeded without making any irreversible changes that risked data loss. E.g. using device-mapper to try out the device in advance of the partition table change with the PV header sectors mapped somewhere else and using some of the advanced lvm.conf options that take metadata from elsewhere. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Shrinking LVM partition at beginning
Outline of the process: Work out the new layout as best you can. vgcfgbackup the metadata into a text file. Update partition table moving the start of the partition, being careful to respect any alignment restrictions. Edit the text file based on the new partition start location so that all the data will be in the same place (so all extent numbers will be smaller by the same fixed amount, and dev_size and pe_start values will change). pvcreate with --restorefile and -Zn to format the "new" partition for LVM's use based on the edited file. vgcfgrestore from that file. Alasdair ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
