[opensuse-factory] Agenda for tomorrow's distribution meeting
Here're the agenda itmes that we plan to discuss tomorrow. Please send input/ask questions etc and I'll bring your input into the meeting. Note that not everything discussed is something that will end automatically in 10.2 - we might reject or postpone some stuff. * PolicyKit/resmgr Continuing discussion from last time. * crypto FS Kay proposes to replace cryptsetup with: http://luks.endorphin.org/dm-crypt LUKS is a standardized media encryption key handling and on-disk metadata format. Usually it's used with a dm-crypt device-mapper device. The cryptseup-luks tools are intended as a complete, backwards-compatible replacement for the original cryptsetup. LUKS stores a crypto-volume header at the beginning of the volume, so it can be safely probed and detected. Keys and encryption metadata are stored in the header of the volume. For details, see: http://luks.endorphin.org/about http://luks.endorphin.org/LUKS-on-disk-format.pdf The complete LUKS crypto Desktop support is already fully implemented in HAL and GNOME (including password-prompt, automount, password storage in gnome-keyring). The SUSE repository only misses an official version of the low-level tools, every other major distribution already ships it. * Removing build dependencies, speeding up the build process Richard proposes to remove dependencies so that building of a complete distribution can be speed up. * GNOME 2.16 and /usr Schedule/plan * /dev/hd removal: http://lkml.org/lkml/2006/8/9/285 * Building distribution for i386/x86-64 with -mtune=generic Proposal: Build distribution with these flags. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger a écrit :
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
beware than scsi disk attribution was never clear in linux: when a disk is mounted, to find where it is is very often extremely difficult. one can have /dev/sd, sr0, 1,5,1... depending of the application (not to insist on differences between distributions) this _must_ be cleared out before any change, thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Mittwoch, 30. August 2006 10:46 schrieb Andreas Jaeger:
* crypto FS
Kay proposes to replace cryptsetup with: http://luks.endorphin.org/dm-crypt [...]
Well, he's not the first one ;-) Quoting my comment from https://bugzilla.novell.com/show_bug.cgi?id=57472#c6: Using DM-Crypt and Cryptsetup-LUKS would have several advantages: - multiple (max. 8) passwords for a partition - so each user can have its own password - passwords can be changed without re-encrypting the whole partition BTW: There was an interesting article about this in the german Linux-Magazin 08/2005 if someone is interested in the details. -> Using DM-Crypt is a very good idea :-)
* Removing build dependencies, speeding up the build process
Also a good idea - but please make sure not to accidently remove features (some configure scripts probe at runtime which libraries for databases etc. are available)
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
If the replacement is /dev/sd*, it's not a very good idea because sd* supports only 15 partitions... What about doing it the other way round - only use the /dev/hd* namespace and drop /dev/sd*? (Well, this is probably a very naive question ;-) Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz
Hello,
Am Mittwoch, 30. August 2006 10:46 schrieb Andreas Jaeger:
* crypto FS
Kay proposes to replace cryptsetup with: http://luks.endorphin.org/dm-crypt [...]
Well, he's not the first one ;-)
;-)
Quoting my comment from https://bugzilla.novell.com/show_bug.cgi?id=57472#c6:
Using DM-Crypt and Cryptsetup-LUKS would have several advantages: - multiple (max. 8) passwords for a partition - so each user can have its own password - passwords can be changed without re-encrypting the whole partition
BTW: There was an interesting article about this in the german Linux-Magazin 08/2005 if someone is interested in the details.
-> Using DM-Crypt is a very good idea :-)
OK.
* Removing build dependencies, speeding up the build process
Also a good idea - but please make sure not to accidently remove features (some configure scripts probe at runtime which libraries for databases etc. are available)
Yes, agreed.
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
If the replacement is /dev/sd*, it's not a very good idea because sd* supports only 15 partitions...
What about doing it the other way round - only use the /dev/hd* namespace and drop /dev/sd*? (Well, this is probably a very naive question ;-)
Read the URL - this is discussed upstream on the lkml mailing list, we're just responding, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Aug 30, 2006 at 12:40:40PM +0200, Christian Boltz wrote:
If the replacement is /dev/sd*, it's not a very good idea because sd* supports only 15 partitions...
Well, my personal opinion about that is that if someone has more than 15(!) partitions on a _single_ IDE disk then either his use case is extremely screwed or he should generally rethink whether he can provide some serious arguments on why he is doing things the way he does it. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Wed, Aug 30, 2006 at 10:46:11AM +0200, Andreas Jaeger wrote:
* Removing build dependencies, speeding up the build process
Richard proposes to remove dependencies so that building of a complete distribution can be speed up.
What do you mean here? Remove dependencies that are not actually required? In that case I am all for it but don't actually know what to discuss about that. Remove all dependencies? I guess this is not what you mean because this does not really make sense. Anything else?
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
I'd like to see that. It's just that you need a reliable update path from old installations but I guess you thought about that.
* Building distribution for i386/x86-64 with -mtune=generic
Proposal: Build distribution with these flags.
I don't have benchmark numbers for this but if it is faster and does not generally break stuff then this does make sense. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
El Miércoles, 30 de Agosto de 2006 01:46, Andreas Jaeger escribió:
* PolicyKit/resmgr
PolicyKit and resmgr are quite similar in the their goal. As PolicyKit is part of HAL, and HAL is necessary to run openSUSE anyway, it would make sense to support PolicyKit and drop resmgr. Even more so if PolicyKit will be a dependency of HAL in the (near?) future. What i don't know: Is PolicyKit is already mature enough to replace the already working solution resmgr. What I am missing in both packages is some kind of tool that lets me actually tap into the power of hal/PolicyKit/resmgr and define my own rules for accessing the computer resources. As a desktop guy I would prefer a nice GUI, but even a bare set of templates for some common usage scenarios like multiuser, terminal server, etc. would help. -- Gruß Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 30, 2006 at 07:11:27AM -0700, Andreas wrote:
El Miércoles, 30 de Agosto de 2006 01:46, Andreas Jaeger escribió:
* PolicyKit/resmgr
PolicyKit and resmgr are quite similar in the their goal. As PolicyKit is part of HAL, and HAL is necessary to run openSUSE anyway, it would make sense to support PolicyKit and drop resmgr. Even more so if PolicyKit will be a dependency of HAL in the (near?) future. What i don't know: Is PolicyKit is already mature enough to replace the already working solution resmgr.
No. PolicyKit is a new thing and just becoming part of HAL. Its code sucks, its thinking sucks. We might be able to influence it towards a better way, eg resmgr.
What I am missing in both packages is some kind of tool that lets me actually tap into the power of hal/PolicyKit/resmgr and define my own rules for accessing the computer resources. As a desktop guy I would prefer a nice GUI, but even a bare set of templates for some common usage scenarios like multiuser, terminal server, etc. would help.
You can with resmgr. ;) Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El Miércoles, 30 de Agosto de 2006 07:14, Marcus Meissner escribió:
PolicyKit is a new thing and just becoming part of HAL.
Its code sucks, its thinking sucks.
I don't know about the code, but yeah, after trying to decrypt the diagramm /usr/share/doc/PolicyKit-0.2_git20060822/spec/polkit-arch.png I believe the thinking behind it is somewhat 'different' ;)
We might be able to influence it towards a better way, eg resmgr.
Reading the HAL mailing list I got a different impression :(
What I am missing in both packages is some kind of tool that lets me actually tap into the power of hal/PolicyKit/resmgr and define my own rules for accessing the computer resources. As a desktop guy I would prefer a nice GUI, but even a bare set of templates for some common usage scenarios like multiuser, terminal server, etc. would help.
You can with resmgr. ;)
care to elaborate? I couldn't find anything. -- Gruß Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 30, 2006 at 07:47:32AM -0700, Andreas wrote:
El Miércoles, 30 de Agosto de 2006 07:14, Marcus Meissner escribió:
PolicyKit is a new thing and just becoming part of HAL.
Its code sucks, its thinking sucks.
I don't know about the code, but yeah, after trying to decrypt the diagramm /usr/share/doc/PolicyKit-0.2_git20060822/spec/polkit-arch.png I believe the thinking behind it is somewhat 'different' ;)
We might be able to influence it towards a better way, eg resmgr.
Reading the HAL mailing list I got a different impression :(
What I am missing in both packages is some kind of tool that lets me actually tap into the power of hal/PolicyKit/resmgr and define my own rules for accessing the computer resources. As a desktop guy I would prefer a nice GUI, but even a bare set of templates for some common usage scenarios like multiuser, terminal server, etc. would help.
You can with resmgr. ;)
care to elaborate? I couldn't find anything.
/etc/resmgr.conf for basic setting up, and calling "/sbin/resmgr ..." from your root scripts to adjust on hotplug events or similar. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El Miércoles, 30 de Agosto de 2006 08:08, Marcus Meissner escribió:
/etc/resmgr.conf for basic setting up, and calling "/sbin/resmgr ..." from your root scripts to adjust on hotplug events or similar.
Thank you. I will look into it :) -- Gruß Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Olaf: You asked for a way to create one dm device per partition in http://lkml.org/lkml/2006/8/10/42 . See the kpartx description below for a solution. Andreas Jaeger wrote:
Here're the agenda itmes that we plan to discuss tomorrow. Please send input/ask questions etc and I'll bring your input into the meeting.
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
Breaks everyone using partitions above hdX15. Two possible solutions: - Use kpartx (and device mapper) for partitions sdX16 and greater (ugly, but works. Booting from such partitions however requires manual mapping in GRUB and LILO) - Change minor number allocation for SCSI disks in the kernel (unlikely to be accepted without great opposition) I'll test using kpartx and report back. Regards, Carl-Daniel -- http://www.hailfinger.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kay: * Can we have a sysfs event if the BLKRRPART ioctl() is called for a given device? This would help implementing more than 16 partitions for libata/scsi and also make partitioned fakeRAID devices easier to handle. * Is there any way to find out when partition detection by the kernel is finished? Or can we instruct the kernel not to detect partitions at all via sysfs? Carl-Daniel Hailfinger wrote:
Olaf: You asked for a way to create one dm device per partition in http://lkml.org/lkml/2006/8/10/42 . See the kpartx description below for a solution.
Andreas Jaeger wrote:
Here're the agenda itmes that we plan to discuss tomorrow. Please send input/ask questions etc and I'll bring your input into the meeting.
* /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
Breaks everyone using partitions above hdX15. Two possible solutions: - Use kpartx (and device mapper) for partitions sdX16 and greater (ugly, but works. Booting from such partitions however requires manual mapping in GRUB and LILO) - Change minor number allocation for SCSI disks in the kernel (unlikely to be accepted without great opposition)
I'll test using kpartx and report back.
This was easier than I thought. You need * partx from util-linux built with --enable-partx * kpartx from multipath-tools Once /sys/block/sdX/ and /sys/block/sdX/sdX[0-9]* appear, run # partx -d /dev/sdX # kpartx -a /dev/sdX and every partition will appear as usual, but in a slightly different place. /dev/sda1 becomes /dev/mapper/sda1 etc. The big difference is that you don't depend on minor number limits anymore (except the usual device-mapper bugs). So /dev/mapper/sda63 is indeed possible. This would all become a lot easier if we 1a. have a way to disable partition detection in the kernel via a knob or 1b. disable in-kernel partition detection by default and do it in userspace with "partx -a /dev/$DISK" when we get a disk_appears event. No change of tools needed, no user-visible changes. 2. (optional) switch to kpartx for partition detection at some point in the future when the tools can handle it. As long as udev works fine (and we get an event on BLKRRPART) the safest solution is 1b and it gives us all the freedom we need to implement the right solution. Regards, Carl-Daniel -- http://www.hailfinger.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (7)
-
Andreas -
Andreas Jaeger -
Carl-Daniel Hailfinger -
Christian Boltz -
jdd -
Marcus Meissner -
Robert Schiele