-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Nov 2013 06:46:05 +0100 Stephan Kulow wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 27.11.2013 23:25, schrieb NeilBrown:

...

On Wed, 27 Nov 2013 19:20:45 +0100 Stephan Kulow wrote:

...

Hi,

It's currently impossible to submit packages from Base:System due to repo-checker blocking submissions as base packages suddenly require krb5.

This is due to a change in libtirpc, that creates a huge cycle. As I'm protecting Factory from having that cycle too, I block such updates. Unfortunately the check hits other packages in the cycle too, so this means: unless this change is reverted, it won't be possible to submit base packages.

Greetings, Stephan

Do really understand much of this, but I'll tell you what I know.

1/ libtirpc doesn't work properly without the recent change. It causes rpc.gssd to crash whenever someone tries to perform a secure NFS mount. 2/ nfs-utils is in Base:System and it already depends on krb5 so I don't understand why this introduces a new dependency.

(just FYI libtirpc is used only by nfs-client, nfs-kernel-server, pam, autofs and rpcbind)

So I don't understand what the problem is, or why there is a problem or what sort of approach might fix it. So I cannot be much help here.

The problem is that pam is used in *every* build environment and so is libtirpc. So if you add further dependencies to libtirpc, you also add more to *every* build environment.

And I don't think that pam requires kerberos - it just doesn't make sense. So I understand that you need that fix for secure NFS mounts, but you don't understand the price tag of that fix. Can we perhaps split either pam or libtirpc's functionality into 2 spec files or do you see any other option?

pam_unix*.so uses libtirpc, presumably for NIS (aka YP) lookup. Do we support kerberos authentication for NIS lookup I wonder. This wasn't a problem before because of libgssglue. This is a wrapper library that maps between libtirpc things and krb5 things. It does some magic run-time loading of krb5 so that isn't a formal dependency on krb5, but if you try any krb5 stuff when krb5 isn't there it will fail. Current krb5 has added support for all the interfaces that libtirpc needs, so libgssglue isn't needed any more. We can still compile both libtirpc and nfs-utils to use libgssglue but that doesn't work either. I think as both krb5 and libgssglue provide the same interfaces (with the same names) and rpc.gssd needs to link to them both, it can get confused and use one interface from one library and on interface from another and it all goes pear-shaped. Upstream doesn't seem interested in libgssglue any more so I don't know how long we will be able to persist with it. I'll have another poke at nfs-utils next week and see if I can make it work with libgssglue. Meanwhile feel free to revert the libtirpc change. I doubt that it is at all easy to split the krb5-accessing part of libtirpc out. Maybe would could split a couple of krb5 libraries out of the krb5 package and only install that package when nfs-utils isn't installed? I think libgssapi_krb5.so.2 libkrb5.so.3 libkrb5support.so.0 would be enough. Does that sound OK? NeilBrown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIVAwUBUpb2bznsnt1WYoG5AQL2nw//QBFk/Whsus7zcSnzTeer4u7P0Ed9PElr 6g9dfAXqZ2w4vDEsVSiyRCLtwJQkd1R/9sFMXkjzVCfargvbxcKylvEsw2v4Qhni PtAj9imbhOEMqBjLphjTTy6o6lIGqbpHKxlS7jzJzazjIKkEzKHbTrAtZsWYQVNT lA9Apn05uAS6KXCfdwQZT6DJlMeJhqUWwzaU17fmTH5/N40UFU86l+QdzYqt1yVt RlP1xnwx0U66zW3Fu9QHHja8UL2GSuNIxh37doG5rvlAIUeMux/SRiLv3ZkUXXc4 +t/JNj36sQE/KxMFvE5CvmahRkX+t2vsHX1t7h7ZO4L1l4Vh8ZOYGkI8rVqFpSXm DJuqRLcvEbTWPJk8o8NOghDAaZGEXNpMoWOOezJ329g0tzvvEJg5P70yNwl3JbCk pZ6X4uDReZKhBSRVj04QWNXs35tEU4S5gyKSO7y1GAulwDfS66wJ32cjSMUwz56d oPzhrQfc1/JEBE11L3ngWn6ezVeaFxtXzrobUXXNKzWpiVdWvtp9Uh7LuAZBWCWe 02baib8c5zdOz/S3EuJqjDYKk3w5Ar4UO8PL7Vg3cn0E7ggAoe853YsFg4vcb/zo mla2FNTAl8v+e7tKkzvFiyLMbP3oGkamkcPPgbmeZmWLvrGkAgjJflgvD4y4Jroh JyMGjIkDZlM= =EnPW -----END PGP SIGNATURE-----

On Thu, 28 Nov 2013, Stephan Kulow wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 28.11.2013 08:53, NeilBrown wrote:

...

Maybe would could split a couple of krb5 libraries out of the krb5 package and only install that package when nfs-utils isn't installed? I think libgssapi_krb5.so.2 libkrb5.so.3 libkrb5support.so.0 would be enough.

Does that sound OK?

We already have krb5-mini (to avoid another cycle). If we can get rid of libgsslglue and krb5-mini is free of further dependencies (which it wasn't last time I tried), we can try.

Note that here also specifically build requirements are important (in addition to install-time requirements). Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 28.11.2013 11:21, NeilBrown wrote:

Once again I have no idea what you mean. In what way, precisely, are build requirements important. In what way might they go wrong? What must we be careful to ensure?

What Richard tries to express is that with bootstrap problems you have to always look at the whole cycle and not just at single packages. Because if you fail to build one package with the rest, you enlarge the cycle. I reverted the change now as you proposed and I tried to setup a staging project for this purpose, but I failed - will continue later Greetings, Stephan -- The coast was clear. -- Lope de Vega -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Dec 2013, NeilBrown wrote:

On Thu, 28 Nov 2013 12:11:34 +0100 Stephan Kulow wrote:

...

On 28.11.2013 11:21, NeilBrown wrote:

...

Once again I have no idea what you mean. In what way, precisely, are build requirements important. In what way might they go wrong? What must we be careful to ensure?

What Richard tries to express is that with bootstrap problems you have to always look at the whole cycle and not just at single packages. Because if you fail to build one package with the rest, you enlarge the cycle.

I reverted the change now as you proposed and I tried to setup a staging project for this purpose, but I failed - will continue later

Greetings, Stephan

I don't know if what I've done will be useful, but I have:

-created an e2fsprogs-mini.spec in e2fsprogs which builds without any dependencies on texinfo or tex.

home:neilbrown:branches:filesystems/e2fsprogs

This requires osc linkpac filesystems e2fsprogs filesystems e2fsprogs-mini to be useful.

-created a version of krb5 which depends on libcom_err-mini-devel (from e2fsprogs-mini) and removes the needless dependency on doxygen

home:neilbrown:branches:networks/krb5

-created a version of libtirpc which depends on krb5-mini rather than krb5.

home:neilbrown:branches:Base:System:libtirpc

and created a submit request for each of those. This should allow libtirpc to be included with minimal extra build dependencies.

Thanks for the effort. Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Jan 02, 2014 at 03:18:21PM +0100, Olaf Kirch wrote:

Hi all,

I'm wondering where we are with this, and what is needed to push this forward. If I'm not terribly mistaken, Neil has done everything that's needed to allow libtirpc to link against krb5-mini. Is there anything else that is needed before we can push this out as an update to 13.1, as well as incorporate it into SLE12?

krb5 was not accepted as e2fsprogs was not accepted. 210411 declined Group: opensuse-review-team 2013-12-10T16:55:03 saschpe fishy unresolvable Because: e2fsprogs was not accepted because a link in filesystem was missing. 211294 Review: declined User: factory-repo-checker 2013-12-17T21:46:12 factory-repo-checker filesystems/e2fsprogs-mini should _link to filesystems/e2fsprogs and I think JeffM had some comments. Ciao, Marcus

Thanks Olaf

On Tuesday 10 December 2013 10:50:41 Richard Biener wrote:

...

...

-created a version of krb5 which depends on libcom_err-mini-devel (from e2fsprogs-mini) and removes the needless dependency on doxygen

home:neilbrown:branches:networks/krb5

-created a version of libtirpc which depends on krb5-mini rather than krb5.

home:neilbrown:branches:Base:System:libtirpc

and created a submit request for each of those. This should allow libtirpc to be included with minimal extra build dependencies.

Thanks for the effort.

Richard.

-- Neo didn't bring down the Matrix. SOA did. (soafacts.com) -------------------------------------------- Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir@suse.com) SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

..... State: accepted 2013-12-10T20:59:43 jeff_mahoney Comment: i'm not thrilled with this, but it seems necessary.

History: new 2013-12-10T20:59:16 jeff_mahoney declined 2013-12-10T03:10:06 jeff_mahoney new 2013-12-10T02:52:21 neilbrown

filesystems:e2fsprogs has the new e2fsprogs-mini.spec etc. We still need someone to osc linkpac filesystems e2fsprogs filesystems e2fsprogs-mini and to propagate that to openSUSE:Factory etc. Who can do that?

NeilBrown

For the Factory it does it by itself. For the filesystems I shall do it now. Cheers Tom

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.01.2014 23:13, schrieb NeilBrown:

Thanks for creating filesystems:e2fsprogs-mini.

It doesn't seem that Factory has done anything by itself. Do we have to wait a particular amount of time, so does it need to be reminded or something? ?? Any help anyone could provide in moving this along would be greatly appreciated.

I have no idea what the actual purpose of this change is actually. libtirpc already links krb5 in factory - wasn't that your goal? Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLTgeoACgkQwFSBhlBjoJZYJwCfWR00Z1ZvFgbMozwAxqYNGoGN WvkAn1PBuJ8ElMrt7zvDNtbGrAz6Vhay =f7YD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Mar 12, NeilBrown wrote:

I then went to find out what had changed to allow things to work now and found in pam.spec (in openSUSE:Factory:pam and SUSE:SLE-12:GA:pam)

#BuildRequires: pkgconfig(libtirpc)

where there used to be

BuildRequires: pkgconfig(libtirpc)

There is no mention of this change in pam.changes and I cannot bring myself to try fighting with "osc log" as it has always disappointed in the past. I don't cannot assign blame (not that blame serves much purpose, so just as well).

It's mentioned in the pam.changes files: ------------------------------------------------------------------- Thu Nov 28 12:00:09 CET 2013 - kukuk@suse.de - Remove libtrpc support to solve dependency/build cycles, plain glibc is enough for now.

has been partly reverted. Are you OK with that Thorsten??

Since I did it: yes, as long as we don't need RPC IPv6 support in Linux-PAM. And currently it doesn't look like. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Thu, 28 Nov 2013, NeilBrown wrote:

...

...

...

Does that sound OK?

We already have krb5-mini (to avoid another cycle). If we can get rid of libgsslglue and krb5-mini is free of further dependencies (which it wasn't last time I tried), we can try.

Note that here also specifically build requirements are important (in addition to install-time requirements).

Richard.

Once again I have no idea what you mean. In what way, precisely, are build requirements important. In what way might they go wrong? What must we be careful to ensure?

The cycles that coolo talks about are build cycles. They are the results of cycles in build dependencies. Build dependencies for package X are the union of its BuildRequires plus the closure union over the Requires and BuildRequires of those. Trivial example: rpm BuildRequires gcc, gcc Requires binutils, binutils BuildRequires gcc, hence there's a (small) cycle rpm-gcc-binutils. There are many more packages entering that particular cycle (which basically is that gcc requires itself to build), e.g. patch, file, expect, expat, flex, bison, cpio, perl, util-linux, zlib, make and so on. Most of these make immediate sense, because they are indeed necessary to create executable from C sources and package them via rpm. One part of that (already large) build cycle is pam, and hence all dependencies of pam, this isn't as obvious, but there are reasons for that (needed by coreutils). As soon as a package enters such a cycle _all_ it's dependencies enter the cycle too. So a package entering a cycle for the first time is potentially a desaster as it can enlargen the cycle by many packages. And it is a desaster because such cycles are handled in a special way by the build service. As long as a package of a cycle is still building no other package (not part of the cycle but depending on it) starts building. And packages in a cycle build until a fixed point is reached (basically until no package build results in a different package than the last build, though the definition of "difference" is a bit convoluted). The result is that packages in a cycle build potentially many times (usually at least twice). The more packages there are in the cycle the higher the chances that the whole thing is built more than twice. So large cycles will tremedously increase the build times for a full rebuild of the respective build tree containing it. Also as soon as any part of a cycle is checked in the whole cycle needs rebuilding, also when the change is in a package that _sounds_ like it's a leaf package. You can see current cycles e.g. for 13.1 at https://build.opensuse.org/project/repository_state/openSUSE:13.1/standard You'll see that libgssglue is in the bootstrap cycle (the one containing gcc/rpm/binutils/glibc). Including krb5 therein will be problematic, it will add much of the python and openldap2 stacks. E.g. checking in python-Sphinx then would lead to a full rebuild of the bootstrap cycle, gcc, glibc, binutils, automake/autoconf, and from there rebuilding _all_ of the distro (because the compiler rebuilt with most probably different resulting rpm). So, one wants to avoid adding to the bootstrap cycle even at _extremely_ large cost in maintaining e.g. several .spec files that have less dependencies. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 28 Nov 2013 12:28:13 +0100 (CET) Michael Matz wrote:

Hi,

On Thu, 28 Nov 2013, NeilBrown wrote:

...

...

...

...

Does that sound OK?

We already have krb5-mini (to avoid another cycle). If we can get rid of libgsslglue and krb5-mini is free of further dependencies (which it wasn't last time I tried), we can try.

Note that here also specifically build requirements are important (in addition to install-time requirements).

Richard.

Once again I have no idea what you mean. In what way, precisely, are build requirements important. In what way might they go wrong? What must we be careful to ensure?

The cycles that coolo talks about are build cycles. They are the results of cycles in build dependencies. Build dependencies for package X are the union of its BuildRequires plus the closure union over the Requires and BuildRequires of those. Trivial example: rpm BuildRequires gcc, gcc Requires binutils, binutils BuildRequires gcc, hence there's a (small) cycle rpm-gcc-binutils. There are many more packages entering that particular cycle (which basically is that gcc requires itself to build), e.g. patch, file, expect, expat, flex, bison, cpio, perl, util-linux, zlib, make and so on. Most of these make immediate sense, because they are indeed necessary to create executable from C sources and package them via rpm.

One part of that (already large) build cycle is pam, and hence all dependencies of pam, this isn't as obvious, but there are reasons for that (needed by coreutils). As soon as a package enters such a cycle _all_ it's dependencies enter the cycle too. So a package entering a cycle for the first time is potentially a desaster as it can enlargen the cycle by many packages.

And it is a desaster because such cycles are handled in a special way by the build service. As long as a package of a cycle is still building no other package (not part of the cycle but depending on it) starts building. And packages in a cycle build until a fixed point is reached (basically until no package build results in a different package than the last build, though the definition of "difference" is a bit convoluted). The result is that packages in a cycle build potentially many times (usually at least twice). The more packages there are in the cycle the higher the chances that the whole thing is built more than twice. So large cycles will tremedously increase the build times for a full rebuild of the respective build tree containing it. Also as soon as any part of a cycle is checked in the whole cycle needs rebuilding, also when the change is in a package that _sounds_ like it's a leaf package.

You can see current cycles e.g. for 13.1 at https://build.opensuse.org/project/repository_state/openSUSE:13.1/standard

You'll see that libgssglue is in the bootstrap cycle (the one containing gcc/rpm/binutils/glibc). Including krb5 therein will be problematic, it will add much of the python and openldap2 stacks. E.g. checking in python-Sphinx then would lead to a full rebuild of the bootstrap cycle, gcc, glibc, binutils, automake/autoconf, and from there rebuilding _all_ of the distro (because the compiler rebuilt with most probably different resulting rpm).

So, one wants to avoid adding to the bootstrap cycle even at _extremely_ large cost in maintaining e.g. several .spec files that have less dependencies.

Thanks for the great explanation! It looks like libtirpc will build OK with BuildRequires: krb5-mini-devel instead of 'krb5-devel'. But that would still add doxygen keyutils libcom_err and then gcc-c++ libpng-devel unzip (for doxygen) I see how this becomes a problem. I wonder if we can make krb5-mini not depend on doxygen. The other dependencies are fairly minor. Or is there some other approach that might be worth pursuing? Thanks, NeilBrown

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.12.2013 05:48, schrieb NeilBrown:

So does that mean we need to create e2fsprogs-mini?? Is it sufficient just to create an e2fsprogs-mini.spec file in the e2fsprogs package, or do we need a separate e2fsprog-mini package, just like there is a separate krb5-mini package? As long as pam can live without libtirpc, there is no need for such drastic measures. removing useless doxygen is great and building against krb5-mini is great too - splitting more packages without need is too expensive.

To update krb5 to exclude doxygen from the -mini build I presumably need to submit updates to both "krb5" and "krb5-mini" - is that correct?

krb5-mini is a 2nd spec file in krb5, you only need to submit krb5. Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKcJYgACgkQwFSBhlBjoJYzBACgmpkH7rYRX80BvnOruoarLvx2 THkAoLGXT69H0ndGoTqSWaeptrDzd55D =2wpY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 28.11.2013 12:01, Thorsten Kukuk wrote:

On Thu, Nov 28, NeilBrown wrote:

...

pam_unix*.so uses libtirpc, presumably for NIS (aka YP) lookup. Do we support kerberos authentication for NIS lookup I wonder.

Several PAM modules uses libtirpc as fallback, but luckly for us, it's only really needed for pam_unix.so. And this one uses it for different tasks.

NIS doesn't use kerberos authentication, only plain RPC.

I couldn't find a place in pam_unix.so where we call RPC functions and are able to support IPv6, so I removed now the libtrpc dependency to pam. But this is only possible as long as no module uses RPC with IPv6. So this is not a long term solution, only short term.

Would it be possible to have a simple module in pam and more advanced functionality in a different package - it can even be required by pam as long as this is requirement does not apply in the build service (bootstrap). I mean - long term ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 28, Yamaban wrote:

IMO a split-out of NIS / YP stuff from pam_unix is needed, or a "pam_unix_minimum" as a replacement. A pam_nis or pam_krb "modul" makes much more sense (as it can be left out of bootstrap).

A pam_nix or pam_krb module doesn't make any sense and will be a nightmare to configure.

No need to pollute the base buildsystem AND just EVERY installed system with kerberos and/or NIS / YP stuff if it isn't needed or wanted. What's the next proposed must-build-in dependency? CIFS(Samba) -- or maybe something else?

There is a difference: CIFS is an external library/package, NIS is integral part of glibc and doesn't pull in other libraries. But we don't speak here about NIS, we speak about IPv6 and RPC. NIS doesn't work at all with IPv6, the protocol is incompatible. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 28 Nov 2013, Michael Matz wrote:

Hi,

On Thu, 28 Nov 2013, Thorsten Kukuk wrote:

...

...

No need to pollute the base buildsystem AND just EVERY installed system with kerberos and/or NIS / YP stuff if it isn't needed or wanted. What's the next proposed must-build-in dependency? CIFS(Samba) -- or maybe something else?

There is a difference:

CIFS is an external library/package, NIS is integral part of glibc and doesn't pull in other libraries.

But we don't speak here about NIS, we speak about IPv6 and RPC. NIS doesn't work at all with IPv6, the protocol is incompatible.

Sure. The last time I looked at the whole pam business is fairly long ago, so what I'll say next will have terminologies and implementation borders wrong, but it somehow must be possible (perhaps by creating a new pam module or hacks or what-have-you) to decrease the requirements of pam _for purposes of the build environment_ which doesn't have network anyway (hence NIS, but also IPv6 and RPC, are irrelevant). That (hacky) pam module or whatever it will turn out to be (perhaps a pam-mini) can be something only used in the build system, and hence can be coming with some hard-coded config that no user will ever touch. (Really, that pam is in the core cycle is the single most reason why it's so godawful difficult to keep it from growing)

It's been long ago since I looked, but the issue is that the bare system (what is required by aaa_base) is too broad for the build system (and also for very stripped installed systems if you consider to populate a chroot - no booting! - that just wants to be able to execute a shell). That is because it requires a 'login' command. Now we could use a different '/bin/login' providing package for the build systems, but really aaa_base should just not require a '/bin/login'. Instead "product meta-data" (whatever that is in its current form) should require things that we think need to be minimally installed. As I said - it was really really long time ago (hackweek 1 or 2, working on Base:install to reduce the size of the minimal installable system). See comments we placed in http://en.opensuse.org/Base_Project at that point in time, especially "Default system configuration should not be done in packages. The rationale behind this is that a default configuration may impose requirements on installed tools (such as pam or ldap) while this choice should be defered to product settings (which thus need to provide a default system configuration in some way). The exact best way to achieve this has not been discussed yet, but the aaa_base package already does parts of that (and would need to be made product specific)." Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, 29 Nov 2013, Ludwig Nussel wrote:

Richard Biener wrote:

...

It's been long ago since I looked, but the issue is that the bare system (what is required by aaa_base) is too broad for the build system (and also for very stripped installed systems if you consider to populate a chroot - no booting! - that just wants to be able to execute a shell).

That is because it requires a 'login' command.

Nowadays login comes from util-linux though.

Bah - my 12.1 still has a separate login package ;) I remember us splitting that from util-linux because util-linux pulls in udev. Well, uphill battle ... ;)

I suppose util-linux is needed anyways so login itself probably isn't the problem anymore.

AFAIK 'login' is the reason we pull in pam at all. And for the build-system chroot we shouldn't need util-linux either ... Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 28, Stephan Kulow wrote:

Would it be possible to have a simple module in pam and more advanced functionality in a different package - it can even be required by pam as long as this is requirement does not apply in the build service (bootstrap). I mean - long term ;)

No, that's not possible. That's basic functionality we even (did?) need in buildservice to setup the build environment. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 29.11.2013 09:43, Thorsten Kukuk wrote:

On Thu, Nov 28, Stephan Kulow wrote:

...

Would it be possible to have a simple module in pam and more advanced functionality in a different package - it can even be required by pam as long as this is requirement does not apply in the build service (bootstrap). I mean - long term ;)

This will not solve your problem.

The RPC implementation in glibc is IPv4 only, means no IPv6. And I don't think that this will ever change, two years ago they even tried to get ride of RPC in glibc completly.

Which means, every application using RPC and IPv6 needs to be linked against libtirpc. And I expect that this number of applications will grow in the next years, not shrink.

So yes, you can start to touch some hundred packages to add workarounds for the libtirpc/krb5 dependency issue, or you can try to find one solution for libtirpc which would solve all of this other packages, too.

Most of these applications are not in the bootstrap cycle, so I don't care. I now submitted libtirpc using krb5 and it did not create another cycle, but only because pam is not requiring it. So all I care about is pam. The pam usage in the build service is limited to one su call (for most packages) and that is not RPC, so I don't care about RPC in the build system. Possibly I can even have a su without pam for this purpose - now that I think about it. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Stephan Kulow wrote:

Possibly I can even have a su without pam for this purpose - now that I think about it.

Maybe su is not needed at all as chroot nowadays has the ability to change uids as well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/29/2013 01:07 PM, Jan Engelhardt wrote:

On Friday 2013-11-29 12:12, Ludwig Nussel wrote:

...

Stephan Kulow wrote:

...

Possibly I can even have a su without pam for this purpose - now that I think about it.

Maybe su is not needed at all as chroot nowadays has the ability to change uids as well.

Nice. Fantastic. Yes, /usr/bin/build should probably just use chroot --userspec if available. One caveat however is that some essential environment variables that pam used to do need to be set manually then, such as HOME.

... and be aware about the groups of the new process: chroot can only add them via the --groups option. Maybe better use 'runuser' (which is util-linux again)? -- Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ludwig Nussel wrote:

Stephan Kulow wrote:

...

Possibly I can even have a su without pam for this purpose - now that I think about it.

Another idea, what about just build ignoring the dependency of pam to krb5? That breaks pam_unix but su as called by the build script skips calling pam_unix.so anyways due to use of pam_rootok.so for auth and account. AFAICS pam_unix doesn't do anything useful in session either (just syslogs the call). So it's 'required' flag in common-sessoin could be changed to 'optional' without negative impact. That way su when called by root would still work despite broken pam_unix

Ah, spoke too fast. That would still make pam require krb5 for building ie keep it in the loop of course. So pam would need to be split up to build the library and the modules separately. Looks doable as well as the modules all live in a subdirectory that could be skipped when building. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 28, Jan Engelhardt wrote:

On Thursday 2013-11-28 12:01, Thorsten Kukuk wrote:

...

On Thu, Nov 28, NeilBrown wrote:

...

pam_unix*.so uses libtirpc, presumably for NIS (aka YP) lookup. Do we support kerberos authentication for NIS lookup I wonder.

Several PAM modules uses libtirpc as fallback, but luckly for us, it's only really needed for pam_unix.so. And this one uses it for different tasks.

It would seem to me that pam_unix should perhaps move to pam-modules, so that the pam core does not depend on anything extra that mere plugins would pull in.

At fist: I don't understand why you include the people from a mailing list into To, too... Second, this would mean you need to add pam-modules to the base packages, which wouldn't solve that problem at all, but makes it worse. Third, this will not solve the RPC/IPv6 issue, if, in the end, you move everything from pam to pam-modules. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 28, Jan Engelhardt wrote:

On Thursday 2013-11-28 13:53, Thorsten Kukuk wrote:

...

At fist: I don't understand why you include the people from a mailing list into To, too...

When replying, Cc is kept as-is, and From is turned into To. That is how mail programs work, and IMHO should work.

Then you should change your mail client, if you answer to a mailing list, it should not put the sender into To. At least mutt is able to handle this correct. And if I see that only 2-3 people are not able to replay correct, then it is not "how mail programs work" ... Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Thursday 2013-11-28 22:20, Thorsten Kukuk wrote:

...

Then you should change your mail client, if you answer to a mailing list, it should not put the sender into To. At least mutt is able to handle this correct. And if I see that only 2-3 people are not able to replay correct, then it is not "how mail programs work" ...

And if I see that only 2-4 people are complaining all the time? This discussion has been had before. Result: LKML-style copying practices are acceptable. (Not surprising given it's the default of the Reply function.) See http://en.opensuse.org/openSUSE:Mailing_lists_subscription#Individual_users_....

There are valid reasons both for and against; see also: https://mailman.suse.de/mlarch/SuSE/cloud-devel/2013/cloud-devel.2013.07/msg... However "I don't like receiving two copies" seems like a weak argument to me, because there are ways to avoid that. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org