Re: [HEADS UP] util-linux based on new mount API coming to rawhide/f39

[Ian Kent]

On 21/3/23 20:16, Karel Zak wrote:

  Hey all,


  util-linux v2.39-rc1 coming to rawhide, Release Notes:
  https://kernel.org/pub/linux/utils/util-linux/v2.39/v2.39-ReleaseNotes

  I usually don't report util-linux Fedora updates, but this one is
  special. This new version provides libmount with support for new
  kernel mount API (syscalls fsconfig, fsmount, open_tree, etc.).

  Some kernel parts may not be fully ported to the new API. Unfortunately,
  the reliable way to detect possible issues is to test all less usual use
  cases and mount options combinations in the real distribution.

  For example, a well-known issue is btrfs when mixed with selinux mount
  options. In this case, libmount falls back to the classic mount(2)
  syscall. We need to gather all such cases.

  If you see any unexpected behavior, please report it to
  https://github.com/util-linux/util-linux/issues, the ideal report is
  with libmount debug output (LIBMOUNT_DEBUG=all mount /foo ...).


Does this handle file systems that have not been converted to the

new mount API?


A while ago I noticed David's autofs conversion patch hasn't been

merged. I started work on simplifying and dividing his patch into

smaller ones but haven't completed it yet.


Is that going to cause problems?


Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: static USERMODEHELPER_PATH

[Ian Kent]

On 6/1/23 10:12, Steve Grubb wrote:

Hello,

I want to add some missing information...

On Thursday, January 5, 2023 8:43:34 PM EST Ian Kent wrote:

On 6/1/23 09:17, Steve Grubb wrote:

I work on RHEL security problems. I have been looking into a number of
exploits and I think we have a problem that has an easy fix.

Here's some examples of what I'm look in at:

https://twitter.com/ETenal7/status/1506708119757328385
https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/
https://etenal.me/archives/1825
https://twitter.com/ky1ebot/status/1539820418479009792
https://github.com/theori-io/CVE-2022-32250-exploit
https://seclists.org/oss-sec/2022/q3/154

etc


We are not
using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There
are a number of exploits that overwrite the path to modprobe and then
pass something weird that causes modprobe to be invoked. But instead of
modprobe, it's their reverse shell.

If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and
we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/
kernel/core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h,
then it limits any exploits to programs that are in /usr.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
kernel/umh.c?h=v5.15#n371


Right, but the above description isn't quite how these config

options are meant to work.


To be maintainable in Fedora the way in which we utilize the bits

that are setup to do this type of thing would need to be inline

with the way they are intended to be used.

CONFIG_STATIC_USERMODEHELPER enables this,
CONFIG_STATIC_USERMODEHELPER_PATH allows you to specify the path
to the binary through with "all" usermode helper invocations are
done.

So we would need to write something that validates its own path
and the path of the thing to be invoked and, if all is ok, execute
the program.

The problem I see with this is that modprobe isn't the only thing
used with umh, there are a number of other things that use this so
some care is going to be needed in what is done and how it's done.

The idea of only allowing specific path prefixes sounds ok since
it's simple, fairly safe, umh kernel users really should be using
programs in "safe" locations, so this all sounds doable ... I'm
sure there will be a bunch of gotchas ...

Ian


Only root can
write here, therefore no escalation. Typically, an exploit changes
modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and
an area the attacker can control.

For this mitigation, we'd need to:

1) set the config option in the kernel build
2) update /proc/sys/kernel/modprobe however it's set
(CONFIG_MODPROBE_PATH)
3) update /proc/sys/kernel/core_pattern however it's set

If we fix the modprobe path issue, there are a couple other areas that
call usermode helper such as handle_initrd, fork_usermode_driver,
CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch
ups.

The benefit is a lot of privilege escalation attacks are taken away.

Does this sound worthwhile? Would people support this? Does this need to
be filed as a system wide change? Who could help make this happen if
approved?

It sounds worth while to me, ;)

Thanks for the initial vote of confidence. It's 3 am in Europe, so I'll wait a
bit for feedback.

-Steve
  

I'd be up for helping with it.

As much as I hate working in the proc file system I can try
and work out what needs to be done for the proc file system
bits.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: static USERMODEHELPER_PATH

[Ian Kent]

On 6/1/23 09:17, Steve Grubb wrote:

Hello,

I work on RHEL security problems. I have been looking into a number of
exploits and I think we have a problem that has an easy fix. We are not using
the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number
of exploits that overwrite the path to modprobe and then pass something weird
that causes modprobe to be invoked. But instead of modprobe, it's their
reverse shell.

If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we
change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/kernel/
core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it
limits any exploits to programs that are in /usr. Only root can write here,
therefore no escalation. Typically, an exploit changes modprobe path to /tmp/
foo which is shorter than /usr/sbin/modprobe and an area the attacker can
control.

For this mitigation, we'd need to:

1) set the config option in the kernel build
2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH)
3) update /proc/sys/kernel/core_pattern however it's set

If we fix the modprobe path issue, there are a couple other areas that call
usermode helper such as handle_initrd, fork_usermode_driver,
CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups.

The benefit is a lot of privilege escalation attacks are taken away.

Does this sound worthwhile? Would people support this? Does this need to be
filed as a system wide change? Who could help make this happen if approved?


It sounds worth while to me, ;)


I'd be up for helping with it.

As much as I hate working in the proc file system I can try

and work out what needs to be done for the proc file system

bits.


Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

[Ian Kent]

On Thu, 2021-10-28 at 10:41 -0400, Simo Sorce wrote:
> On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote:
> > Stephen John Smoogen  writes:
> > 
> > > Mainly because it is the authentication service equivalent of
> > > telnet**. Very simple to set up, very simple to use, and very
> > > easy to
> > > steal all the information about logins, users, and setups. [...]
> > 
> > ... well, compared to what?  LDAP commonly distributes crypttext
> > passwords and databases with about the same amount of discernment
> > and
> > theft-enablement as ypserv.  Plaintext as in telnet makes an
> > appearance
> > nowhere but with yppasswd, AFAIK, which is nonessential.
> 
> LDAP is normally deployed on a secure channel (TLS or GSSAPI), that
> the
> client can cryptographically check.
> 
> NIS is a clear text protocol that can be trivially MitMed to provide
> arbitrary information to the target system.
> 
> Also generally LDAP *does not* in fact distribute passwords, most
> systems use the LDAP Bind operation to test a password and the LDAP
> server does *not* provide access to password hashes.
> 
> 
> I thin k it is legitimate to question whether it is yet time to drop
> this obsolete protocol (NIS) on backwards compatibility grounds.
> But on security grounds it is indefensible, don't go there.

There's no question NIS has poor security, as bad a using a local
password plus shadow file anyway. People that use it must know
that. The valid use is company internal only, on systems whose
data is freely available to company personnel and where accounts
and groups info. isn't security critical.

It's been that way for many, many years ... it's no secret.

It's a pity NIS+ was such a pain to setup and use ... a bridge
to far IMHO ... 

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

[Ian Kent]

On Wed, 2021-10-27 at 13:40 -0400, Matthew Miller wrote:
> On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote:
> > == User Experience ==
> > For some users this change may be a bit disruptive and it may
> > require
> > some learning curve for switching to alternative solutions.
> 
> I've spoken with some of my sysadmin friends and universities, and
> they
> suggest that the above is enough of an understatement to feel
> insulting.
> 
> They would like, at least, more time than F36 to adjust to this, and
> broader
> communication that we plan to drop it.

Remind me, why is NIS support being dropped?

Personally I thought it was a bad idea from the first I heard of it
and never saw any actual valid reasons to do so. I was simply told
to drop it from my package which I did.

Ian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ian Kent]

On Mon, 2021-08-30 at 07:55 +0200, Ondrej Dubaj wrote:
> Hi,
> 
> Thank you for the update Ian. It was not meant the way every packager
> is ignoring the opened issues, we appreciate your work on this
> autoconf-2.71 issue. Sorry for generalizing this.

And my comment was not meant to sound negative, getting an update
like this done is very challenging, to say the least, hopefully
everything will go well, ;)

Truth is I would have liked to get it done earlier but was unable
to, at least I have managed to get it done now.

> 
> Glad to hear that it will build OK today.
> 
> HEADS-UP:
> 
> Starting with merging autoconf-2.71 changes. This week a scratch-
> build for all dependent packages will be executed. If you want to
> test your packages by yourself, you can execute your own scratch-
> build and see if it works properly. I will write here when autoconf-
> 2.71 will be stable.
> 
> Thanks for your cooperation and hope to see very few failures this
> week :)
> 
> Regards,
> Ondrej
> 
> On Fri, Aug 27, 2021 at 2:36 PM Ian Kent  wrote:
> > On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> > > Hello,
> > > 
> > > In the near future, there is a plan to merge autoconf-2.71 to
> > > rawhide. Due to the size of the change and possible breakage of
> > > multiple packages going FTBFS. The number of these packages
> > > should
> > > not be many, currently we have ~32 opened FTBFS trackers
> > > according
> > to
> > > autoconf-2.71, where the majority of them are just ignored by
> > > maintainers [1]. This can also be a possibility to remove
> > unnecessary
> > > packages from Fedora. After merging the change, there should be a
> > > mechanism for validating. From my perspective, it is effective to
> > > rebuild dependent packages (~1700 packages). After the rebuild,
> > there
> > > should not be many FTBFS packages, but according to the change
> > there
> > > will be some. There was enough time (~6 months) for the
> > > maintainers
> > > to prepare for this change. 
> > 
> > Not everyone is ignoring the bugs I have been working on the am-
> > utils
> > package for this.
> > 
> > The package is very old and it utilizes autoconf very heavily.
> > Most of the autoconf noise is use of obsolete macros and I have
> > updated
> > this were I can but there are some things I simply can't fix and
> > some
> > things that shouldn't be changed.
> > 
> > I'll keep coming back to it over time since the changes I have made
> > or
> > (rather will be committing over the weekend) do allow the package
> > to
> > build and function on F33 and build in the Copr updated autoconf
> > environment.
> > 
> > I expect it will build ok on Monday.
> > 
> > > 
> > > If there are any concerns or other opinions about the steps after
> > > merging the change, please share your thoughts and we can discuss
> > > them here.
> > > 
> > > Thanks very much!
> > > 
> > > Regards,
> > > Ondrej
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> > > 
> > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> > > wrote:
> > > > Hello, according to the size of this change and the possible
> > > > breakage of multiple packages before f35 mass rebuild, we
> > > > decided
> > > > (team working on this change) to postpone this change to early
> > > > lifecycle of f36, where we will have enough time to resolve any
> > > > problems until f36 mass rebuild.
> > > > 
> > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi 
> > wrote:
> > > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > > > Currently, we are trying to stay away from the compat
> > > > > > package
> > > > > > and
> > > > > with the
> > > > > > help of other package maintainers trying to fix the
> > > > > > failures.
> > > > > > We
> > > > > will give
> > > > > > time to react accordingly and see other possible steps in a
> > few
> > > > > weeks time.
> > > > > > 
> > > > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > > > according
> > > > > to
> > > > > > autoconf-2.71. More information available here:
> > > > > > 
> > > >

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ian Kent]

On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> Hello,
> 
> In the near future, there is a plan to merge autoconf-2.71 to
> rawhide. Due to the size of the change and possible breakage of
> multiple packages going FTBFS. The number of these packages should
> not be many, currently we have ~32 opened FTBFS trackers according to
> autoconf-2.71, where the majority of them are just ignored by
> maintainers [1]. This can also be a possibility to remove unnecessary
> packages from Fedora. After merging the change, there should be a
> mechanism for validating. From my perspective, it is effective to
> rebuild dependent packages (~1700 packages). After the rebuild, there
> should not be many FTBFS packages, but according to the change there
> will be some. There was enough time (~6 months) for the maintainers
> to prepare for this change. 

Not everyone is ignoring the bugs I have been working on the am-utils
package for this.

The package is very old and it utilizes autoconf very heavily.
Most of the autoconf noise is use of obsolete macros and I have updated
this were I can but there are some things I simply can't fix and some
things that shouldn't be changed.

I'll keep coming back to it over time since the changes I have made or
(rather will be committing over the weekend) do allow the package to
build and function on F33 and build in the Copr updated autoconf
environment.

I expect it will build ok on Monday.

> 
> If there are any concerns or other opinions about the steps after
> merging the change, please share your thoughts and we can discuss
> them here.
> 
> Thanks very much!
> 
> Regards,
> Ondrej
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> 
> On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> wrote:
> > Hello, according to the size of this change and the possible
> > breakage of multiple packages before f35 mass rebuild, we decided
> > (team working on this change) to postpone this change to early
> > lifecycle of f36, where we will have enough time to resolve any
> > problems until f36 mass rebuild.
> > 
> > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
> > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > Currently, we are trying to stay away from the compat package
> > > > and
> > > with the
> > > > help of other package maintainers trying to fix the failures.
> > > > We
> > > will give
> > > > time to react accordingly and see other possible steps in a few
> > > weeks time.
> > > > 
> > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > according
> > > to
> > > > autoconf-2.71. More information available here:
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > > 
> > > Whats the current status of this Change?
> > > 
> > > It didn't land before mass rebuild. Is it still planned for f35?
> > > 
> > > kevin
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to 
> > > devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var

[Ian Kent]

On Sun, 2020-10-25 at 20:38 -0600, Chris Murphy wrote:
> On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel
> 
> > I also intend to do the same with /sys on this, my beta system,
> 
> I'm not sure about this. /sys is a pseudo-filesystem, the contents
> aren't really on the root file system.

That's right, like /proc is a proc file system, /sys is a sysfs file
system (similar to other pseudo file systems). They are memory based
and files are generated on access, proc files mostly directly from
kernel data structures, and sysfs mostly from an rb-tree data structure
within the sysfs file system populated at boot.

You must mount /sys as a sysfs file system in order for the rb-tree
to be populated, you can't make it a btrfs file system (or any other
file system for that matter).

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ditch RPM in favor of DPKG

[Ian Kent]

On Thu, 2020-07-16 at 10:11 +, Dridi Boukelmoune wrote:
> > Simply put, "no". Debian and Ubuntu ".deb" packages too often don't
> > follow the File System Hierarchy, they may have different layouts
> > and
> > package naming capitalization schemes for matching Fedora packagers
> > like "PyYAML", they may have overlapping pre-set uids and
> > mismatched
> > group name conventions, etc., etc, and the grub intigration for new
> > kernels is likely to be a nightmare. It would be a full-time job
> > for
> > several competent engineers to do that kind of package impedance
> > matching.
> 
> I'm not interested in debating Debian and derivatives packaging
> guidelines, but I generally prefer how Fedora does things (except
> notably, modularity).

I have to say that, from my perspective due to past experience, having
to use the Debian/Ubuntu packaging for development in Fedora would
have me scrambling to find another distribution for my desktop.

While dpkg is just a learning curve thing, rpm is much simpler when
doing development/bug fixing for me. Indeed the fact that Fedora used
rpm is one of reasons I have continued to use Fedora for my desktop
for so many years.

Oddly, the subject of the original post infers getting rid of rpm but
the post itself sounds like it's proposing something different and
that's why I decided to speak up.

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: 1794117 – Disabling support for UDP for NFSv3

[Ian Kent]

On Wed, 2020-01-22 at 14:25 -0500, Steve Dickson wrote:
> FYI... 
> 
> NFS over UDP will be deprecated in the 5.6 kernel. 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1794117
> 
> Its not clear what or if any havoc this could cause
> but the commit (f745bfdc) has been accepted upstream.
> Just letting the community know...  

Yeah, that's going to be a problem for am-utils.

It's been a while but IIRC there was a bug that I fixed in
the single-threaded concurrent mount handling that requires
UDP to work properly, not to mention the completely
unnecessary TCP overhead for the localhost (limited function)
server of the amd daemon.

It's not my doing the daemon implemented the concurrent mounting
this way, it was done many years ago, I just fixed the bug I
found. I also don't think re-implementing the concurrent mounting
is an option and neither is converting amd to use pthreads which
I think are the only ways around this.

I implemented an NFSv3 server for amd when NFSv2 was dropped and
while implementing an NFSv4 server might not be that all that
difficult I really would rather not go there, especially since
there's nothing to gain from doing it.

There would need to be a decent number of am-utils package users
that can demonstrate that they can't use the amd format map support
now present in the Linux autofs automounter. I accept that the way
autofs handles amd maps internally (necessarily) isn't the same as
that of amd and amd users might not be terribly happy with it but
that's the way it is. To change that would be a very significant
amount of work that may or may not work in the end and will almost
certainly disrupt existing functionality and still not get entirely
the same behaviour.

Speaking of behaviour, I mean the way mounts are performed internally
not semantic behaviour, amd format maps should themselves behave as
expected for the amd map features that are supported in autofs (and
that's a fairly large portion of the amd functionality).

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to install a mountpoint directory from an rpm?

[Ian Kent]

On Fri, 2019-05-03 at 00:30 -0400, Nico Kadel-Garcia wrote:
> On Tue, Apr 30, 2019 at 8:25 PM Ian Kent  wrote:
> > 
> > On Tue, 2019-04-30 at 17:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:
> > > > On 4/30/19 11:45 AM, David Howells wrote:
> > > > > Hi,
> > > > > 
> > > > > I need to install a directory (/afs) that will be a mountpoint that a
> > > > > systemd
> > > > > service (also installed in the rpm) will mount upon.
> > 
> > I seem to remember you can't create root level directories from a
> > program either.
> 
> Of course you can. The program needs to run with root privileges. and
> not violate whatever SELinux or other "/" mountpoint restrictions
> exist.

What I'm referring to is (must have been) the selinux rules because
automount(8) needs to be run as root.

> 
> It's a *Bad Idea(tm), since it violates the File System Hierarchy, but
> that hardly makes it impossible.

That's debatable but I'm not going to argue about it, but do disagree
with this for the case of long time existing system services such as
autofs.

> 
> > So the user needs to create these directories manually!
> > 
> > That problem hasn't been reported for a while so this may have changed.
> > 
> > > 
> > > Nope. New top-level directories are a big thing and need FPC approval:
> > > 
> > 
> > 
https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=528452#Filesystem_Layout
> > > (I can't find the text in the new guidelines, but the new guidelines don't
> > > support searching, so finding anything is PITA, so I'll just assume that
> > > this is still valid...)
> > 
> > That's a great idea.
> > 
> > So, as has been happening, I have to advise users that they must create
> > any mount point directories they need in / manually before starting autofs.
> 
> Or better yet, in /opt/ or /usr/local/ or /var/lib/ or whatever makes
> the most sense with the File System Hierarchy.

That imposes a restriction on the system administrator, although
/usr/local makes sense in some cases and is sometimes used, but
it depends on the file system names space the administrator wants
to use to get naming consistency while also keeping path names as
short as possible.

This actually makes quite a difference for sites that have a large
number of files and directories in their automount mount trees.

> 
> > It's this sort of policy that makes me want to close bugs for this without
> > any explanation of why the problem occurs!
> > > Regarding the FPC approval: I don't think it should be granted. There
> > > is no good reason to create a mount point like this under root. It should
> > > go
> > > somewhere under /run or /var.
> > 
> > Rubbish, the package is following long standing conventions, there's no
> > good reason to prevent this and, while it may be possible in this case,
> > it's not always possible to know what directory (or directories) will
> > need to be created therefore it's not possible to seek approval.
> 
> \And violating a much more important, namely the File System Hiearchy.
> If you can find a good reason to violate that, publish your reasoning.
> 
> By the way, I've dealt with /afs style automounting before, and it was
> a nightmare to clean up after when it inevitably croaked precisely due
> to the root filesystem location of "/afs".

Yes, there can problems from time to time with automounting.

autofs has a command line option to clear out all existing mounts
at startup so you can start over but it's not exactly straight
forward to use now we use systemd (at least I'm not aware of a
way to add custom actions to units).

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to install a mountpoint directory from an rpm?

[Ian Kent]

On Tue, 2019-04-30 at 17:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:
> > On 4/30/19 11:45 AM, David Howells wrote:
> > > Hi,
> > > 
> > > I need to install a directory (/afs) that will be a mountpoint that a
> > > systemd
> > > service (also installed in the rpm) will mount upon.

I seem to remember you can't create root level directories from a
program either.

So the user needs to create these directories manually!

That problem hasn't been reported for a while so this may have changed.

> 
> Nope. New top-level directories are a big thing and need FPC approval:
> 
https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=528452#Filesystem_Layout
> (I can't find the text in the new guidelines, but the new guidelines don't
> support searching, so finding anything is PITA, so I'll just assume that
> this is still valid...)

That's a great idea.

So, as has been happening, I have to advise users that they must create
any mount point directories they need in / manually before starting autofs.

It's this sort of policy that makes me want to close bugs for this without
any explanation of why the problem occurs!

> 
> Regarding the FPC approval: I don't think it should be granted. There
> is no good reason to create a mount point like this under root. It should go
> somewhere under /run or /var.

Rubbish, the package is following long standing conventions, there's no
good reason to prevent this and, while it may be possible in this case,
it's not always possible to know what directory (or directories) will
need to be created therefore it's not possible to seek approval.

> 
> Zbyszek
> 
> 
> > > 
> > > What's the best way to encode this in the specfile?
> > > 
> > > I did have:
> > > 
> > >   %files
> > >   /afs
> > > 
> > > but that doesn't upgrade correctly.  Someone gave me another way to do it:
> > 
> > Just create it on your %install section
> > 
> >   mkdir $RPM_BUILD_ROOT/afs
> > 
> > and continue adding the reference on the %files like:
> > 
> > %file
> > %dir /afs
> > 
> > > 
> > >   %post
> > >   %systemd_post afs.mount
> > > 
> > >   # Create /afs directory if it doesn't exist
> > >   if [ ! -d /afs ]; then
> > >   mkdir /afs
> > >   chown root.root /afs
> > >   chmod 0755 /afs
> > >   [ -x /usr/sbin/restorecon ] && /usr/sbin/restorecon /afs
> > >   fi
> > > 
> > >   %files
> > >   %ghost %dir /afs
> > > 
> > > but rpmlint complains about the chown:
> > > 
> > >   kafs-client.x86_64: W: dangerous-command-in-%post chown
> > > 
> > > The git repo is here:
> > > 
> > >   
> > > http://git.infradead.org/users/dhowells/kafs-client.git/shortlog/refs/heads/next
> > > 
> > > 
> > > The second patch from the top is the one that tries to fix the mountpoint
> > > dir
> > > installation issue ("spec: Treat /afs special").
> > > 
> > > Thanks,
> > > David
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: AMD ROCm

[Ian Kent]

On Mon, 2019-01-21 at 12:58 +0100, Felix Schwarz wrote:
> Am 21.01.19 um 09:11 schrieb Ian Kent:
> > As much as I would like to help I need to get an additional SSD
> > for my NUC8i7HNK (Radeon™ RX Vega M GL graphics) for that (I hope
> > fairly soon).
> > 
> > And I think the Vega needs a later version of ROCm as well.
> 
> Yes, AFAIK Vega M is not (yet?) supported by amdkfd. Also ROCm is mostly
> developed/tested for more powerful hardware so I would not hold my breath for
> Vega M support.

Of course, yes, but I live in hope and I'd like to get familiar
with ROCm!

> 
> Anyway I'm happy to test packages with my Polaris card but I have to admit I
> don't feel "knowledgeable" enough to review a more complex package like "hcc".
> Probably it would help just doing the normal review process (except actually
> running the binary).

Either way it's hard to properly test something like this.

I think the focus needs to be primarily on packaging so that we
can help upstream along by simply making it available.

That obviously implies developing a relationship with upstream
which is often lacking in distributions with many packages (for
obvious reasons).

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: AMD ROCm

[Ian Kent]

On Mon, 2019-01-21 at 08:39 +0100, Felix Schwarz wrote:
> Am 09.01.19 um 11:50 schrieb Germano Massullo:
> > AMD ROCm - Open Source Platform for HPC and Ultrascale GPU Computing[1]
> > is packaged by upstream only for RHEL/CentOS and Ubuntu.
> > Is anybody working on packaging it for Fedora? If not, is anybody
> > interested in setting up a team to work on it?
> 
> Just wanted to mention that Tom Stellard has some open review requests for
> rocminfo and hcc:
> https://bugzilla.redhat.com/show_bug.cgi?id=1666836
> https://bugzilla.redhat.com/show_bug.cgi?id=1545479
> 
> Reviewers welcome :-)

As much as I would like to help I need to get an additional SSD
for my NUC8i7HNK (Radeon™ RX Vega M GL graphics) for that (I hope
fairly soon).

And I think the Vega needs a later version of ROCm as well.

> 
> Btw: I terminated perl license checker script after 8h continuous CPU usage
> (only 1 core though) when running "fedora-review" for hcc. Is that a known
> problem for bigger software? (hcc bundles llvm).
> 
> Felix
> 
> PS: If you want to test on F29, please rebuild hsakmt/rocm-runtime from
> rawhide before.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: AMD ROCm

[Ian Kent]

On Wed, 2019-01-09 at 11:50 +0100, Germano Massullo wrote:
> Hello,
> AMD ROCm - Open Source Platform for HPC and Ultrascale GPU Computing[1]
> is packaged by upstream only for RHEL/CentOS and Ubuntu.
> Is anybody working on packaging it for Fedora? If not, is anybody
> interested in setting up a team to work on it?

Interesting approach to HPC.

Might be a useful way for me to get some exposure to HPC which
I'd like to do.

> 
> Have a nice day
> 
> [1]: https://rocm.github.io/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nsswitch.conf: list of module packages that enables themselves

[Ian Kent]

On Mon, 2018-11-26 at 14:38 +0100, Pavel Březina wrote:
> On 11/26/18 2:21 PM, Stephen Gallagher wrote:
> > On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:
> > > 
> > > This e-mail is long so I just put the question here before explanation:
> > > 
> > > Do you know about any package that installs an nsswitch.conf module and
> > > automatically enables it in /etc/nsswitch.conf? So far I have two
> > > packages - nss-mdns and systemd.
> > > 
> > > Why?
> > > 
> > > As you might have noticed, in Fedora 28 we switched from authconfig to
> > > authselect. This brought some adoption issues and feature requests which
> > > we tried hard to resolved, mostly related to nsswitch.conf. Thank you
> > > for all your feedback.
> > > 
> > > At this point I am aware of only one nsswitch.conf related issue that we
> > > would like to fix. The problem is that when you choose to use authselect
> > > you are no longer allowed to touch /etc/nsswitch.conf (and various file
> > > in /etc/pam.d) manually but you should use authselect and its profiles
> > > instead.
> > > 
> > > However, this does not work well for small environments (possibly single
> > > user machines) where you want to just change something in nsswitch.conf
> > > and do not want to create custom profile. For this, we introduced
> > > /etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
> > > command to do this the authselect way (of course you are free to not use
> > > authselect and just modify the files manually).
> > > 
> > > But there are some packages that installs nsswitch modules and
> > > automatically puts them in /etc/nsswitch.conf in %post which conflicts
> > > with authselect. We would like to provide an authselect call for these
> > > packages, that would make sure it does not conflict with authselect [1].
> > > 
> > > I started working on a design for such feature and I'm trying to obtain
> > > list of all packages that installs nsswitch modules and automatically
> > > enable them in /etc/nsswitch.conf.
> > > 
> > > So far I was able to find these packages:
> > > - nss-altfiles
> > > - nss_db
> > > - nss-mdns
> > > - nss_nis
> > > - nss-pam-ldapd
> > > - nss_updatedb
> > > - sssd
> > > - systemd
> > > 
> > > But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
> > > you know about any other package?
> > > 
> > > Thank you,
> > > Pavel.
> > > 
> > > [1] https://github.com/pbrezina/authselect/issues/77
> > 
> > 
> > IIRC, doesn't autofs also use nsswitch.conf for configuration?
> 
> Yes, but it is not part of glibc. AFAIK it works similar to sudo - 
> lookup automount line in nsswitch.conf and acts according to its 
> settings. But it does not have proper support in glibc.

Yes, automount uses the "automount:" line of nsswitch.conf.

It doesn't mess with nsswitch.conf and I'm not willing to
change a file autofs doesn't own, it's the users responsibility
to set the autofs map sources they need.

Umm .. "proper" ... I'll take that to just mean I don't use
the glibc API rather than a criticism of what I chose to do.

Originally I tried to use the glibc API and I even had autofs
specific nsswitch example code but I found I couldn't do what
I needed. When I did this I didn't have time to work through
the glibc API code to work out if it did provide what I needed
so I wrote my own parser.

If I need to change that then I'll need pointers to adequate
glibc nsswitch API documentation as I still don't want to dive
into the glibc code to work out how do this.

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What services / tools still require NIS domain?

[Ian Kent]

On 16/05/18 23:17, David Kaspar [Dee'Kej] wrote:
> On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher  > wrote:
> 
> I don't think SSSD or FreeIPA *require* it. They offer netgroup 
> functionality that can be used with it. Maybe I misunderstood your question? 
> Are you just asking which things in the distro interact with NIS domains at 
> all?
> 
> Perhaps it would be better if you explained the rationale for the 
> question. For example, are you trying to figure out if we can remove all of 
> NIS from the distro?
> 
> 
> ​Sorry, I don't know much about NIS. I was coming out from what I've been 
> told.

I think you'll find NIS is still quite widely used.

NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely used.
LDAP is another attempt to provide much of the table information provided by NIS
but it is far more complicated to administer.

NIS remains the simplest and easiest way to centrally manage (key, value) stores
such as password, group, netgroup, hosts etc. so it has endured.

Automount maps are another (key, value) store that can be centrally managed by
NIS and there are still a surprising number of autofs users that continue to
use it.

> 
> I'm trying to figure out, which application / tool / service still actually 
> need the fedora-domainname.service to be present in Fedora in order to 
> function correctly?

The question is kind-off ambiguous.

It's not so much applications that need the service but rather services
that can utilize the (key, value) information stored in NIS tables for the
functionality they provide that need the NIS domain to be set.

For example autofs can use NIS as an automount map source but it doesn't
depend on NIS, it can also use automount maps stored in files, LDAP, sss
etc.
 
Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

devel@lists.fedoraproject.org

[Ian Kent]

On 07/04/18 10:13, Tomasz Kłoczko wrote:
> On 6 April 2018 at 22:58, Pierre-Francois RENARD  wrote:
>> Hello guys,
>>
>> with F28 I tried to use autofs and nfs.
> 
> BTW autofs: is it any particular reason why in Fedora kernels autofs
> support is compiled into the kernel and is not provided as loadable
> module?
> 
> $ cat /proc/filesystems | grep auto; echo; lsmod | grep auto
> nodev autofs

Yes there is a reason.

Long ago there were two autofs modules that provided the autofs
file system, autofs and autofs4. So kernel module auto-loading
didn't work for autofs4.

Now the autofs module has long since been removed and many times
I have prepared a patch series to rename autofs4 to autofs but
haven't been able to post them as something higher priority has
always come up.

So yes, I need to do that, but it may also be the case that it's
considered to be frequently enough used that it will continue to
be compiled in.

> 
> $
> 
> PS. the same is with for example ext{2..4} support.
> 
> $ cat /proc/filesystems | grep ext; echo; lsmod | grep ext
> ext3
> ext2
> ext4

Not sure about those but ext3 and ext4 are probably compiled in
because they are frequently used, ext2 maybe should be a module
nowadays, but not my call.

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

devel@lists.fedoraproject.org

[Ian Kent]

On 07/04/18 05:58, Pierre-Francois RENARD wrote:
> Hello guys, 
> 
> with F28 I tried to use autofs and nfs. 
> I had the following error “Too many levels of symbolic links”
> I had to change SELinux mode to permissive to be able to make autofs usable 
> ... 

I had a report that appeared to be selinux related but I haven't see this one.
Could you log a bug please, include systemd journal output with "logging = 
debug"
set in /etc/autofs.conf.

What autofs package revision are you using?

> 
> 
> But I also discovered that by default mount.nfs and autofs are using NFSv4 
> and cannot switch to NFSv3. 
> I had to add an option to /etc/sysconfig/autofs << OPTIONS=" -O vers=3" >> so 
> autofs use by default NFSv3... 

I'm not sure what you mean?
autofs doesn't impose an nfs version if it isn't specified in the map.
It depends on how mount.nfs(8) is configured.

Historically, if you wanted to use NFSv3 (to prevent starting negotiation at
NFSv4) you needed to set "Defaultvers=3" in /etc/nfsmount.conf. You also
needed to set "mount_nfs_default_protocol = 3" in /etc/autofs.conf to prevent
autofs doing unnecessary NFSv4 availability probes.

Of course the other way to do this is to specify the mount option in the map
some other way, and as you said setting "-O vers=3" is one possible way.

> 
> I had the following error message with the command
> mount -t nfs syno01:/volume1/data /tmp/data
> mount.nfs: Protocol not supported
> 
> and no error with 
> mount -t nfs -o vers=3 syno01:/volume1/data /tmp/data

Sounds like an nfs-utils problem, probably best to log a bug on that.

> 
> 
> Is it a normal behaviour or did I miss something ? 

No, not usually but we haven't looked at the map configuration or the debug logs
yet so I'm not sure.

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rpcgen?

[Ian Kent]

On 09/01/18 23:31, Florian Weimer wrote:
> On 01/09/2018 03:32 PM, Steve Dickson wrote:
>>
>>
>> On 01/09/2018 06:10 AM, Richard W.M. Jones wrote:
>>>
>>> https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&oldid=508864
>>> says:
>>>
>>>    "Packages which need rpcgen will have to add BuildRequires: 
>>> libtirpc-devel to their spec files."
>>>
>>> but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.
>> Nor will it... There is going to be a new package call rpcsvc-proto
>> that will contain the rpcgen command along with other things
>> like header files... There is the upstream git tree:
>>     http://github.com/thkukuk/rpcsvc-proto
>>
>> Here is the Review Request for the package, if interested.
>>     https://bugzilla.redhat.com/show_bug.cgi?id=1532364
> 
> Note that the plan is that the new package will provide rpcgen, so you can 
> just use
> 
> BuildRequires: rpcgen
> 
> and you'll get the new package once it becomes available.

What can I do in the meantime to build autofs in Rawhide?

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gdb: No symbol table info available

[Ian Kent]

On 10/12/17 02:13, Richard Shaw wrote:
> I'm working on a segfault in the latest version of hedgewars and I can 
> reproduce the crash easy enough and I have installed both the debuginfo for 
> hedgewars and all the packages gdb suggested but the end of the log[1] still 
> says:

Getting all the debuginfo packages that are needed to analyze a core can be 
quite a
challenge.

Did you install all the dependent debuginfo packages?

debuginfo-install hedgewars

Even then there might have some missing.

Once all the dependent debuginfos are installed you could look at the core
to try and find out what's missing with (coredump is the core here):

eu-unstrip -n --core coredump |\
gawk '{TMP=$2; $1=$2=""; print "/usr/lib/debug/.build-id/" substr(TMP,0,2) 
"/" substr(TMP,3,38) $0}'

Using the output from above dnf can be used to work out what's missing
with somewhat less guess work than usual, eg.

dnf provides /usr/lib/debug/.build-id/be/b9dc6f92875b3faa920e09241e8ab98b0e7c27

etc.

> 
> No symbol table info available.
> 
> Any ideas?
> 
> Thanks
> Richard
> 
> [1] $ cat test.log 
> 
> Thread 1 (Thread 0x77fa7300 (LWP 13966)):
> #0  __GI__dl_catch_error (objname=0x28d6c30, errstring=0x28d6c38, 
> mallocedp=0x28d6c28, operate=0x765d4ff0 , args=0x2946aa0)
>     at dl-error-skeleton.c:187
>         errcode = 32767
>         c = {objname = 0x291f050, errstring = 0x291f670, malloced = 
> 0x28d6c28, errcode = 0x7fffd724, env = {{__jmpbuf = {281479271743488, 1, 
>                 281479271743489, 65537, 281479271743489, 140733193388033, 
> 281479271743489, 3340499160213259264}, __mask_was_saved = 65537, 
>               __saved_mask = {__val = {43280784, 0, 140737289327168, 
> 43280792, 45365184, 0, 3340499160213259264, 0, 43280272, 43280272, 
>                   140737289327168, 0, 140737488345416, 140737289324280, 
> 140737323254718, 0}
>         old = 0x2b437c0
> #1  0x765d56a5 in _dlerror_run (operate=operate@entry=0x765d4ff0 
> , args=0x2946aa0) at dlerror.c:163
>         result = 0x28d6c20
> #2  0x765d501f in __dlclose (handle=) at dlclose.c:46
> No locals.
> #3  0x74027bee in CleanupVendorNameEntry 
> (pEntry=pEntry@entry=0x2946790, unused=0x0) at libglxmapping.c:321
>         vendor = 0x2946790
> #4  0x7402a161 in __glXMappingTeardown (doReset=doReset@entry=0) at 
> libglxmapping.c:1061
>         cur__GLXvendorNameHash = 0x2946790
>         tmp__GLXvendorNameHash = 0x0
>         pEntry = 
>         tmp = 
> #5  0x74022dd7 in __glXFini () at libglx.c:2099
>         glas = 
> #6  0x77de74b3 in _dl_fini () at dl-fini.c:235
>         array = 0x742306f0
>         i = 
>         l = 0x28d7160
>         maps = 0x7fffd8a8
>         i = 
>         l = 
>         nmaps = 
>         nloaded = 
>         ns = 0
>         do_audit = 
>         __PRETTY_FUNCTION__ = "_dl_fini"
> #7  0x76239fc8 in __run_exit_handlers (status=0, listp=0x765ce5b8 
> <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
>     run_dtors=run_dtors@entry=true) at exit.c:83
>         atfct = 
>         onfct = 
>         cxafct = 
>         f = 
> #8  0x7623a01a in __GI_exit (status=) at exit.c:105
> No locals.
> #9  0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0, 
> init=, fini=, rtld_fini=, 
>     stack_end=0x0) at ../csu/libc-start.c:329
>         result = 
>         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0, 4217114, 
> 140737488346352, 4210861, 140737322809482, 140737322809482, 
>                 140737300163376}, mask_was_saved = -8968}}, priv = {pad = 
> {0x2dd10, 0x404084 , 0x0, 0xb0bfd26695729445}, data = {
>               prev = 0x2dd10, cleanup = 0x404084 , canceltype 
> = 0}}}
>         not_first_call = 
> #10 0x in ?? ()
> No symbol table info available.
> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs bug - any info on bugzilla 1324635

[Ian Kent]

On Wed, 2016-06-01 at 17:15 -0700, Jagga Soorma wrote:
> Hi Guys,
> 
> Anyone have any information on bugzilla 1324635.  This seems like a private
> bug being tracked by redhat but is major and impacting us.  Basically nfs gets
> impacted with large writes.

It looks to me like there's work being done on it but no-one can reproduce the
problem on demand and no-one is willing to test possible fixes to get feedback.

It also looks to me like an extremely difficult problem to resolve so as much
help as possible is needed to get to the bottom of it (if in fact it can be
resolved in the short(ish) term).

Are you able to help by providing vmcores or testing kernels?
Have you spoken to RedHat support about it?

Ian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Ian Kent]

On Wed, 2016-02-03 at 18:44 -0700, Kevin Fenzi wrote:
> On Thu, 04 Feb 2016 09:09:33 +0800
> Ian Kent  wrote:
> 
> > I agree.
> > 
> > I believe that package ownership has at least a couple of clear
> > advantages for obvious reasons and I find it hard to understand how
> > people can discount their usefulness.
> > 
> > 1) A point of contact and co-ordination for changes is needed.
> > 
> > Often, when dealing with difficult problems it's necessary to seek
> > advice from maintainers of other packages. Being able to find out who
> > that is and having at least some chance they will be familiar with
> > upstream package status is important.
> > 
> > 2) Taking (even notional) ownership of a package implies there is at
> > least some interest in the package from an upstream POV.
> > 
> > Some (probably many) packages need a packager to take an interest in
> > what is happening upstream. Building relationships with upstream
> > maintainers doesn't always work too well but even that is an
> > important part of knowing what the upstream status of a package is.
> > 
> > This is essential to be able to provide 1) above, someone who has some
> > understanding of the upstream status really is needed to at least
> > help keep our packages as stable as we can.
> > 
> > It's true that package owners don't always have enough upstream
> > knowledge of packages they own or relationships with upstream but
> > that doesn't mean that ownership is a bad thing. After all a point of
> > contact is still needed IMHO.
> 
> I agree with what you are saying, but disagree that anything above
> requires you to "own" packages and guard them from anyone else. 
> 
> You can still be a point of contact and/or interested upstream and want
> to help keep the packages in Fedora high quality and working, but still
> be willing to work as part of the entire collection of maintainers not
> isolated or defensive. We all want to improve things, even if we make
> mistakes doing so. 

Sure, anyone that argues against this is not playing well with others.
But I do feel like my use of "owner" has been misunderstood.

I certainly don't mind if changes are made to packages I look after, it
happens and is mostly not a problem.

So I think the problem being discussed won't be resolved by changing to a
model of not having a package "owner" (however that's defined), it's not
process or policy, it's behavioural based.

That's probably not going to change no matter what efforts are made to change
processes and policy.

So I don't really know what to say to improve matters, sorry.

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Ian Kent]

On Wed, 2016-02-03 at 16:04 +, Jonathan Wakely wrote:

> > If I send these two provenpackagers a somewhat hostile email, are you
> > going to blame me?  I have no problem with most provenpackager
> > changes.  In general, they have an obvious purpose and save me the
> > work of making the same change myself.  But changes like the ones
> > above make more work for me, work that could have been avoided if the
> > provenpackager in question had just bothered to make some attempt, any
> > attempt, to contact me first.
> 
> I don't think that's always realistic to expect.
> 
> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way to get things fixed. Waiting for a reply adds
> a lot of latency, and then you have to context-switch back to a
> package you were dealing with a day or two ago. That's impractical
> when you have a patch ready to go now and loads more packages to look
> at.
> 
> Sometimes a provenpackager will make a bad change, and that's
> unfortunate, but it happens. Sometimes package owners make bad changes
> too! :-)
> 
> If I make a bad change to a package please do let me know. If I appear
> to change things and walk away it's probably because I've moved on to
> look at other packages that also need attention, not just a careless
> hit & run. I would expect it's similar for others.

Sorry but this sounds more like a process definition problem than anything.

In fact, problems like this sound like they would be better dealt with by
alerting the package maintainer and passing the ball to them. If the problem
isn't dealt with quickly enough then perhaps that package should not be re
-built at this time. There should be some responsibilities for package
maintainers.

And, surely, in this case the provenpackager has too much to do to pay
suitable attention to changes needed and really does need to move on.

Yes, there would be some need to define process around this so the ball could
come back to a provenpackager on a second pass, hopefully when they have a
little more time to attend to the problem, if there was no response from the
maintainer.

This reminds me of the saying "more haste less speed"!

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Ian Kent]

On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote:
> 
> I think we need to ask ourselves, as a project, what behaviors we want
> to motivate and what behaviors we want to demotivate in our packagers.
> I think we need to take human nature, flawed as it is, into account
> when doing so.  I fear that this "nobody owns any packages" mantra is
> not providing the motivations and demotivations that we really want.

I agree.

I believe that package ownership has at least a couple of clear advantages for
obvious reasons and I find it hard to understand how people can discount their
usefulness.

1) A point of contact and co-ordination for changes is needed.

Often, when dealing with difficult problems it's necessary to seek advice from
maintainers of other packages. Being able to find out who that is and having
at least some chance they will be familiar with upstream package status is
important.

2) Taking (even notional) ownership of a package implies there is at least
some interest in the package from an upstream POV.

Some (probably many) packages need a packager to take an interest in what is
happening upstream. Building relationships with upstream maintainers doesn't
always work too well but even that is an important part of knowing what the
upstream status of a package is.

This is essential to be able to provide 1) above, someone who has some
understanding of the upstream status really is needed to at least help keep
our packages as stable as we can.

It's true that package owners don't always have enough upstream knowledge of
packages they own or relationships with upstream but that doesn't mean that
ownership is a bad thing. After all a point of contact is still needed IMHO.

I fail to see how allowing ad-hoc changes to packages, which will often not
even involve letting others interested in the package know what has happened,
will lead to improvement overall.

If the goal is to reduce the barrier for others to contribute then that
doesn't necessarily mean doing away with package owners. It means defining
processes to allow this while keeping the owner (the one that probably has
some idea of the upstream package status) in the loop. Whether that also means
power of veto over changes is slightly different but somehow I think that must
be the case to maximize package stability.

It might be obvious that my view is influenced a lot because I'm also an
upstream package maintainer.

Clearly I strongly believe in the need for downstream packagers to be in touch
with what's happening upstream. And, yes, it can be hard to take the "no" or
"I don't like that change" or an "I'm not going to do that" but that is all
part of working with upstream and knowing a package, the bit downstream
packagers seem to miss all too often IMHO.

Don't forget, the relationship (that is needed) is just as hard for upstream
as it is for downstream, that's just life.

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [INPUT REQUESTED] Fedora Policy on generated code

[Ian Kent]

On Sat, 2015-12-19 at 00:34 +0100, Lars Seipel wrote:
> There may be reasonable exceptions, but I'd consider them pretty
> rare.
> Even outside of the context of licensing, I think the concept of
> "preferred form for modification" is a useful one here. That's what
> should be in the SRPM and should be compilable by FOSS tools
> available
> in Fedora. If upstream development regularly happens by hand-editing
> a
> yacc-generated parser and no one touched the original grammar file in
> years, then sure, it's probably best to ship the generated files.

If that is the case then the generated code is no longer generated code
but source that must be maintained independently.

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: STOP messing with nfs-utls... PLEASE!!!

[Ian Kent]

On Wed, 2015-11-04 at 06:28 -0500, Steve Dickson wrote:
> Hey,
> 
> On 11/04/2015 01:35 AM, Ian Kent wrote:
> > > I feel this is a better way to handle these issues
> > > > than the bootstrapping option (which will be
> > > > reverted from nfs-utils).
> > I think I've addressed these.
> > 
> > But we probably should do one last version bump in fedfs-utils and
> > autofs to ensure everything still builds properly when it's
> > reverted,
> > correct?
> > 
> I already verified both fedfs-utils and autofs build without nfs
> -utils,
> but nfs-utils is still required to install fedfs-client and fedfs
> -server.

Looks like the compose went ok too, based on the mail I saw.

It makes sense for fedfs-utils-client and fedfs-utils-server to require
nfs-utils doesn't it?

Ian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: STOP messing with nfs-utls... PLEASE!!!

[Ian Kent]

On Tue, 2015-11-03 at 14:41 -0500, Steve Dickson wrote:
> In conclusion (which is why I'm top posting)
> 
> Two bzs have been open up in other packages:
> To take out the circular dependency in fedfs-utils
>https://bugzilla.redhat.com/show_bug.cgi?id=1277666
> 
> and remove a bad nfs-utils dependency in autofs
>https://bugzilla.redhat.com/show_bug.cgi?id=1277669
> 
> I feel this is a better way to handle these issues
> than the bootstrapping option (which will be
> reverted from nfs-utils).

I think I've addressed these.

But we probably should do one last version bump in fedfs-utils and
autofs to ensure everything still builds properly when it's reverted,
correct?

> 
> So please lets move any more conversation to 
> one of those two bugs. Thank you!
> 
> steved.
>  
> On 11/03/2015 09:42 AM, Steve Dickson wrote:
> > I realized over the weekend the following 
> > commits were make to fix the build and 
> > they did not!! The build is just as
> > broken as before!!!
> > 
> > Now I have to go back an figure out 
> > what has changed which takes even 
> > more time!!!
> > 
> > Its not like I'm not around or unreachable
> > So please stop these fly by night comments 
> > and let me do my job! 
> > 
> > steved.
> > 
> > commit 6ea94b72ac9dfdb6c6d93f8bf975c23c578b9ba0
> > Author: Kalev Lember 
> > Date:   Sun Nov 1 16:42:33 2015 +0100
> > 
> > Enable bootstrap
> > 
> > Add a bootstrap conditional to avoid circular nfs-utils ->
> > fedfs-utils
> > -> nfs-utils dependencies when bootstrapping. This makes it
> > possible to
> > rebuild nfs-utils for the libtirpc soname bump.
> > 
> > commit 9a0a0708184a95a307e2746e76d32e816672562f
> > Author: Kalev Lember 
> > Date:   Sun Nov 1 16:01:33 2015 +0100
> > 
> > Drop old %triggerin scripts to unbreak the build
> > 
> > Rebuilding nfs-utils led to rpmbuild erroring out with:
> > 
> > error: line 262: Trigger fired by the same package is already
> > defined in spec file: %triggerin -- nfs-utils < 1:1.3.1-4.0
> > 
> > To fix the build, this commit drops the old %triggerin scripts
> > that
> > rpmbuild doesn't like. We are already at F24; the scripts were
> > there to
> > support upgrades from nfs-utils 1.3.0 that was in F20 and
> > upgrades from
> > F20 were only supported up to F22 on the distro level.
> > 
> > commit 8b7932dd1c91ef34919e8ae76200015b80774605
> > Author: Kalev Lember 
> > Date:   Sun Nov 1 15:40:35 2015 +0100
> > 
> > Rebuilt for libtirpc soname bump
> > 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: STOP messing with nfs-utls... PLEASE!!!

[Ian Kent]

On Tue, 2015-11-03 at 16:26 +0100, Kalev Lember wrote:
> On 11/03/2015 04:08 PM, Steve Dickson wrote:
> > commit 7765dd87e174beaa44a16a89530d4b956d9abdba
> > Author: Kalev Lember 
> > Date:   Sun Nov 1 16:48:00 2015 +0100
> > 
> >  Disable bootstrap
> > 
> > commit 6ea94b72ac9dfdb6c6d93f8bf975c23c578b9ba0
> > Author: Kalev Lember 
> > Date:   Sun Nov 1 16:42:33 2015 +0100
> > 
> >  Enable bootstrap
> > 
> > Maybe some one can explain to me what
> > was being tried... that didn't work?
> 
> Why do you think it didn't work? These two commits are what made it
> possible to rebuild fedfs-utils.
> 
> If you look two lines down below, this commit has a long commit
> message
> (which you've cut out in the email) explaining what bootstrap does.
> 
> Just to reiterate: your packages had a cyclic dependency, nfs-utils <
> ->
> fedfs-utils <-> nfs-utils. Both of them depend on libtirpc. In koji,
> it
> is only possible to rebuild one package at a time; to be able to do
> that
> you need to first break the cyclic chain so that the other package
> can
> be installed in the build root.

Truth be told that the circular dependency was my fault.

There may have been some sense to it way back when we wanted to ensure
that the nfs-utils package had nfs junction support but it should have
been removed not too long after.

But the removal didn't happen, apologies to everyone for that.

Ian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Tue, 2015-11-03 at 15:00 +0800, Ian Kent wrote:
> On Mon, 2015-11-02 at 19:55 -0800, Adam Williamson wrote:
> > On Tue, 2015-11-03 at 11:30 +0800, Ian Kent wrote:
> > >  
> > > Still, with COPR I would need to find a suitable location to put
> > > the
> > > repo. so perhaps the mock method would suit me better.
> > 
> > COPR *is* a repo. All you need to do is log in, create a new COPR
> > repo,
> > and you can upload SRPMs and it will build them. The repo is part
> > of
> > its own buildroot, so any time you build a package in a COPR repo,
> > subsequent builds in the same COPR repo build against it.
> 
> My bad, initially I got the impression it was necessary to provide a
> url to external packages which seemed a bit strange. I intend to
> return
> for a closer look when I have time so I'll do that.

Oh again, I get what you were saying, what I meant was I thought an
external url to the new packages you wanted to build was needed, not a
url to to the repo to build against, ;)

I guess I can need to ignore that field and look for a way to upload anSRPM 
after the create.

> 
> Thanks
> Ian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Mon, 2015-11-02 at 19:55 -0800, Adam Williamson wrote:
> On Tue, 2015-11-03 at 11:30 +0800, Ian Kent wrote:
> >  
> > Still, with COPR I would need to find a suitable location to put
> > the
> > repo. so perhaps the mock method would suit me better.
> 
> COPR *is* a repo. All you need to do is log in, create a new COPR
> repo,
> and you can upload SRPMs and it will build them. The repo is part of
> its own buildroot, so any time you build a package in a COPR repo,
> subsequent builds in the same COPR repo build against it.

My bad, initially I got the impression it was necessary to provide a
url to external packages which seemed a bit strange. I intend to return
for a closer look when I have time so I'll do that.

Thanks
Ian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Mon, 2015-11-02 at 18:46 -0800, Adam Williamson wrote:
> On Tue, 2015-11-03 at 09:49 +0800, Ian Kent wrote:
> >  
> > This policy is clearly sensible and necessary, no question about
> > that.
> > 
> > But this appears to be an opportunity for improvement as well.
> > 
> > Fortunately the breakage looks like it should be straight forward
> > to
> > resolve but that obviously might not always be the case.
> > 
> > For my part I wonder if getting advanced notice would have helped
> > because I'm not sure what the process is to properly work through a
> > staging environment and build test process.
> > 
> > Going about it the long way could mean a week might not be long
> > enough.
> > 
> > There must be a process that doesn't involve having to go through
> > quite
> > a bit of work on my local machine when that sort of infrastructure
> > should be available via the repository and build system or a
> > documented
> > process of steps for building locally.
> 
> Well, see the last suggestion in my mail, about using COPR.
> http://copr.fedoraproject.org/

Yes, that does look useful and TBH I hadn't checked what COPR had to
offer until I saw your previous response.

The steps you outlined in that reply were also useful for local builds,
thanks for putting in the effort to describe it.

Still, with COPR I would need to find a suitable location to put the
repo. so perhaps the mock method would suit me better.

There must be others that would find what you wrote useful for this
case, how do I go about requesting the Policy be updated (just
slightly, to include basically what you wrote)? 

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin .
> net
> http://www.happyassassin.net
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Mon, 2015-11-02 at 11:15 -0800, Adam Williamson wrote:
> On Mon, 2015-11-02 at 11:02 +0800, Ian Kent wrote:
> > On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> > > On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > > > On Fri, 30 Oct 2015 11:50:48 -0400
> > > > Steve Dickson  wrote:
> > > > > 2) find and rebuild all the dependencies?
> > > > 
> > > > Should be something like: 
> > > > 
> > > > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > > > Last metadata expiration check performed 0:01:17 ago on Fri Oct
> > > > 30
> > > > 10:34:06 2015.
> > > > autofs-1:5.1.1-3.fc23.x86_64
> > > > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > > > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > > > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > > > nfs-utils-1:1.3.2-10.fc23.x86_64
> > > > rpcbind-0:0.2.3-0.2.fc23.x86_64
> > > 
> > > Now that the libtirpc update is in, I tried to kick off rebuilds
> > > for
> > > these to make them them installable again in rawhide (they are
> > > breaking
> > > nightly image composes). Didn't get very far with this though
> > > because
> > > rpcbind and fedfs-utils are failing to build and are blocking
> > > others:
> > > 
> > > rpcbind (
> > > http://koji.fedoraproject.org/koji/buildinfo?buildID=69540
> > > 4)
> > > failed with:
> > > 
> > > src/rpcb_svc_com.c: In function 'handle_reply':
> > > src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> > > __rpc_svcxprt}' has no member named 'xp_auth'
> > >   xprt->xp_auth = &svc_auth_none;
> > > 
> > > and fedfs-utils (
> > > http://koji.fedoraproject.org/koji/buildinfo?buildID=695402)
> > > failed
> > > the same way:
> > > 
> > > gss.c: In function 'fedfsd_get_gss_cred':
> > > gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> > > member named 'xp_auth'
> > >   auth = rqstp->rq_xprt->xp_auth;
> > 
> > Steve is aware of this, or will be soon, as it was raised on the
> > upstream libtirpc mailing list.
> > 
> > So we need to wait until rpcbind is updated before we can go
> > further
> > with this.
> 
> Folks, this is not okay. This is not the right way to do things. If
> you
> aren't reasonably sure that all the library's consumers can be made
> to
> work with the new version of the library, *don't put the new version
> in
> Rawhide*. Rawhide isn't a dumping ground for random new code and has
> not been for some time. It is not okay to just break the entire thing
> and say 'we'll fix it once we've finished the upstream work'. The
> upstream work needs to happen *before* you break Rawhide.
> 
> We're doing all this work across several teams to compose and test
> Rawhide regularly, and it's kind of pointless if people are just
> going
> to break the whole thing gratuitously. Please do not do this.
> 
> Policy:
> 
> https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_m
> aster
> 
> Note that that clearly says "A week in advance, notify maintainers
> who
> depend on their package to rebuild when there are abi/api changes
> that
> require rebuilds in other packages or offer to do these rebuilds for
> them." *A WEEK IN ADVANCE*. This bump was submitted to Koji on the
> *same day* it was notified, 2015-10-30. That is a clear violation of
> the policy. I would argue the policy also assumes fairly strongly
> that
> rebuilds of dependent packages will in fact be possible, but I'd
> suggest we amend the policy to explicitly state that soname bumps and
> other incompatible changes should not be done *at all* unless there
> is
> a clear plan to make all dependent packages compatible immediately.

This policy is clearly sensible and necessary, no question about that.

But this appears to be an opportunity for improvement as well.

Fortunately the breakage looks like it should be straight forward to
resolve but that obviously might not always be the case.

For my part I wonder if getting advanced notice would have helped
because I'm not sure what the process is to properly work through a
staging environment and build test process.

Going about it the long way could mean a week might not be long enough.

There must be a process that doesn't involve having to go through quite
a bit of work on my local machine when that sort of i

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Mon, 2015-11-02 at 11:02 +0800, Ian Kent wrote:
> On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> > On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > > On Fri, 30 Oct 2015 11:50:48 -0400
> > > Steve Dickson  wrote:
> > > > 2) find and rebuild all the dependencies?
> > > 
> > > Should be something like: 
> > > 
> > > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > > Last metadata expiration check performed 0:01:17 ago on Fri Oct
> > > 30
> > > 10:34:06 2015.
> > > autofs-1:5.1.1-3.fc23.x86_64
> > > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > > nfs-utils-1:1.3.2-10.fc23.x86_64
> > > rpcbind-0:0.2.3-0.2.fc23.x86_64
> > 
> > Now that the libtirpc update is in, I tried to kick off rebuilds
> > for
> > these to make them them installable again in rawhide (they are
> > breaking
> > nightly image composes). Didn't get very far with this though
> > because
> > rpcbind and fedfs-utils are failing to build and are blocking
> > others:
> > 
> > rpcbind (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695404)
> > failed with:
> > 
> > src/rpcb_svc_com.c: In function 'handle_reply':
> > src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> > __rpc_svcxprt}' has no member named 'xp_auth'
> >   xprt->xp_auth = &svc_auth_none;
> > 
> > and fedfs-utils (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
> > the same way:
> > 
> > gss.c: In function 'fedfsd_get_gss_cred':
> > gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> > member named 'xp_auth'
> >   auth = rqstp->rq_xprt->xp_auth;
> 
> Steve is aware of this, or will be soon, as it was raised on the
> upstream libtirpc mailing list.
> 
> So we need to wait until rpcbind is updated before we can go further
> with this.
> 
> I had a look at the libtirpc code and the autofs library pre-open
> might
> still be needed. I didn't yet look far enough to see if there's a
> library unload destructor, which may be all that's needed, to resolve
> this. So I need to get around looking further before posting to the
> upstream list.
> 
> In the mean time I have committed a change to autofs to also pre-open
> the new library.

btw, Chuck Lever (fedfs-utils) was also part of that discussion but he
may not have yet realized fedfs-utils is affected too.

Once the change to be made is decided we should be able to fix these
pretty quickly.

I can commit changes to fedfs-utils if Chuck doesn't have time.

> 
> > 
> > -- 
> > Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > On Fri, 30 Oct 2015 11:50:48 -0400
> > Steve Dickson  wrote:
> > > 2) find and rebuild all the dependencies?
> > 
> > Should be something like: 
> > 
> > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > Last metadata expiration check performed 0:01:17 ago on Fri Oct 30
> > 10:34:06 2015.
> > autofs-1:5.1.1-3.fc23.x86_64
> > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > nfs-utils-1:1.3.2-10.fc23.x86_64
> > rpcbind-0:0.2.3-0.2.fc23.x86_64
> 
> Now that the libtirpc update is in, I tried to kick off rebuilds for
> these to make them them installable again in rawhide (they are
> breaking
> nightly image composes). Didn't get very far with this though because
> rpcbind and fedfs-utils are failing to build and are blocking others:
> 
> rpcbind (http://koji.fedoraproject.org/koji/buildinfo?buildID=695404)
> failed with:
> 
> src/rpcb_svc_com.c: In function 'handle_reply':
> src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> __rpc_svcxprt}' has no member named 'xp_auth'
>   xprt->xp_auth = &svc_auth_none;
> 
> and fedfs-utils (
> http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
> the same way:
> 
> gss.c: In function 'fedfsd_get_gss_cred':
> gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> member named 'xp_auth'
>   auth = rqstp->rq_xprt->xp_auth;

Steve is aware of this, or will be soon, as it was raised on the
upstream libtirpc mailing list.

So we need to wait until rpcbind is updated before we can go further
with this.

I had a look at the libtirpc code and the autofs library pre-open might
still be needed. I didn't yet look far enough to see if there's a
library unload destructor, which may be all that's needed, to resolve
this. So I need to get around looking further before posting to the
upstream list.

In the mean time I have committed a change to autofs to also pre-open
the new library.

> 
> -- 
> Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Fri, 2015-10-30 at 14:16 -0400, Steve Dickson wrote:
> 
> On 10/30/2015 12:36 PM, Kevin Fenzi wrote:
> > On Fri, 30 Oct 2015 11:50:48 -0400
> > Steve Dickson  wrote:
> > 
> > > Hello,
> > > 
> > > Well place sources tell me in the upcoming
> > > libtirpc release the soname will be changing 
> > > due to some API changes. 
> > > 
> > > The API changes will make the Linux version 
> > > more compatible with litbirpc implementations
> > > 
> > > Obviously this change will just go in rawhide
> > > but how do I
> > > 1) request the build rpm go be added to the build root?
> > 
> > That automatically happens after the build completes. It's added in
> > the
> > next newrepo call (so usually 10-20min) 
> > 
> > > 2) find and rebuild all the dependencies?
> > 
> > Should be something like: 
> > 
> > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > Last metadata expiration check performed 0:01:17 ago on Fri Oct 30
> > 10:34:06 2015.
> > autofs-1:5.1.1-3.fc23.x86_64
> > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > nfs-utils-1:1.3.2-10.fc23.x86_64
> > rpcbind-0:0.2.3-0.2.fc23.x86_64
> Perfect!!! 

Steve, at some point I must have found that libtirpc used Thread
Specific Data (TSD) that was problematic because I had seen crashes on
exit as I've seen with other libraries.

Using the TSD functionality isn't a problem unless the clean up
function set at creation belongs to the library itself, which in some
cases simply isn't present when the pthreads clean up code is called at
process exit.

If that's not no longer a problem or I was mistaken in the beginning
then I can remove the workaround from autofs, otherwise I'll need to
update the workaround to also try to pre-open the new library.

Ummm ... I think I'm also be guilty of not raising this upstream ... oo
ps!

> > 
> > > 3) anything else I need to do?
> > 
> > Not off hand. ;) Thanks for the heads up 
> NP... Thanks!
> 
> steved.
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Are we rebasing xorg-x11 packages in F20?

[Ian Kent]

On Tue, 2014-11-25 at 14:04 +0100, Simone Caronni wrote:
> On 25 November 2014 at 13:20, Lukas Zapletal  wrote:
> I don't understand why I noticed this today, it looks like the
> latest
> update was a Critical Path one (???) when Fedora 20 was stable
> for six
> months.
> 
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-7331/xorg-x11-server-utils-7.7-6.fc20
> 
> 
> from what I've seen xorg packages are always marked as Critical Path.
> 
> The update you are referring to is six months old, are you sure the
> xrandr command is the culprit and not something else? Did you skip
> updates for six months?
> 
> 
> There's an intel driver from 18th november, for example:
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20
> 
> 
> 
> This seems to be much more related to your issues. I don't had any
> output renaming recently in the past year (Nouveau here).

FWIW my case is Intel too and this change did occur in the most recent
update, over possibly a week but certainly not two weeks, and the device
naming did change.
 
> 
> 
> Regards,
> 
> --Simone
> 
> 
> 
> 
> 
> -- 
> You cannot discover new oceans unless you have the courage to lose
> sight of the shore (R. W. Emerson).
> 
> http://xkcd.com/229/
> http://negativo17.org/
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Are we rebasing xorg-x11 packages in F20?

[Ian Kent]

On Tue, 2014-11-25 at 09:14 +0100, Lukas Zapletal wrote:
> Hello,
> 
> my desktop was completely broken this morning because my startup scripts
> rely on xrandr utility. An older update from this summer which I applied
> recently changed it's output so device ids now contain dash characters
> (e.g. instead VGA0 I see VGA-1).

Yeah, it's a bit annoying, just got caught by it myself.

I have a simple kvm switch and I can't leave it to defaults or I get a
low res display.

So I have to use a /etc/X11/xorg.conf.d/00-monitor.conf.

> 
> I just wonder why this landed into stable repository. The package
> changelog really shows it's a rolling release kinda thing.
> 
> http://pkgs.fedoraproject.org/cgit/xorg-x11-server-utils.git/log/?h=f20
> 
> I understand some packages has exceptions, like kernel, firmware and
> such things. But xorg tools? Thanks for explanation.
> 
> -- 
> Later,
>  Lukas #lzap Zapletal


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

[Ian Kent]

On Fri, 2014-10-03 at 13:18 +0200, Juan Orti Alcaine wrote:
> El 2014-10-03 11:38, Steven Whitehouse escribió:
> > Hi,
> > I should also add (just in case anybody gets the wrong idea!) that I
> > think it should definitely be made as easy as possible for anybody who
> > wants to evaluate running btrfs on Fedora, but it is far too early to
> > make it the default yet,
> > 
> 
> I agree with your opinion, it's a bit too early. An experienced user can 
> deal with the idiosyncrasies of btrfs and it's great when you learn it, 
> but pushing it as the default seems too adventurous.
> 
> I want to add to the list of problems the performance degradation over 
> time in database-like files (journal, vm images, firefox and other 
> sqlite db). I have experienced minutes of delay consulting the journal 
> in heavily fragmented journal files.

I still have to agree with not making btrfs the default.

Sadly, I see BUG(), ENOSPC error reports (seem to have returned), and
btrfs-progs SEGV reports on the btrfs mailing quite regularly and while
much of the functionality may now be stable all the features of the
default file system will get stressed more than the other file systems,
including the perhaps not so stable ones.

> 
> -- 
> Juan Orti
> https://miceliux.com
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Default libkrb5 ccache location

[Ian Kent]

On Tue, 2013-07-30 at 08:07 -0400, Simo Sorce wrote:
> On Tue, 2013-07-30 at 03:27 +0200, Lennart Poettering wrote:
> > On Mon, 29.07.13 21:11, Simo Sorce (s...@redhat.com) wrote:
> > 
> > > On Tue, 2013-07-30 at 02:08 +0200, Lennart Poettering wrote:
> > > > On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org) wrote:
> > > > 
> > > > > On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
> > > > > > So, why don't you revert to using /tmp then?
> > > > > 
> > > > > The problem with /tmp is that if you want predictable filenames for 
> > > > > the
> > > > > storage, you open yourself to a denial-of-service attack where another
> > > > > user can create a file with the same name.
> > > > 
> > > > Well, but that's not unsurmountable, just pick a randomly named
> > > > directory in /tmp and make sure to have a symlink:
> > > > 
> > > >ln -s /tmp/krb.XX "$HOME/.krb-`cat /etc/machine-id`"
> > > 
> > > What would create this directory ?
> > 
> > The same component that creates the temporary directory?
> > 
> > In pseudo code:
> >
> >char temp[] = "/tmp/krb.XX", link[PATH_MAX];
> >char *machine_id, *home;
> > 
> >mkdtemp(temp);
> >machine_id = get_file_contents("/etc/machine_id");
> >*strchrnul(machined_id, '\n') = 0;
> >home = getenv("HOME);
> >snprintf(link, "%s/.krb-%s", home, machine_id);
> >symlink(temp, link);
> > 
> > Of course, you should skip this if the symlink already exists and points
> > to a valid directory...
> 
> This doesn't make any sense whatsoever, if we are back to unpredictable
> file names and trolling I may as well just use /tmp/krb5cc_XX only.
> 
> Ccaches do not belong in the home directory, period.

Couldn't agree more.
There's no guarantee the home directory will be available when the
credential is needed.
 
> 
> > > > to give it a stable, machine-local name.
> > > 
> > > in what case /tmp contains non-'machine-local' files ?
> > 
> > /tmp doesn't. But /home does. Hence you include the machine ID in the
> > symlink name.
> > 
> > > Also I need one directory per-user and not per-machine.
> > 
> > Well, you want it per-user *and* per-machine.
> > 
> > > And how is this different than /run/kerberos in the end ?
> > 
> > That there's a sane cleanup scheme done via /tmp and not yet another
> > place where we have unrestricted runtime objects of the user.
> 
> Except the stuff that cleans /tmp has no idea how to look *into* the
> ccache to see if it is still valid or not, so it is a mechanism I do not
> care for.
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Stop the git abuse

[Ian Kent]

On Mon, 2012-05-21 at 10:23 +0200, Ralf Corsepius wrote:
> On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> > - Original Message -
> >> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> >>> And definitvely, for me, (and probably only for me), git is really
> >>> not a good tool for spec maintenance.
> >>
> >> Not duplicating the changelog would help.  There's little reason to
> >> have a changelog in git which is then manually copied into
> >> %changelog.
> >
> > +1, for me - GIT is the authority for change logs, not SPEC...
> 
> -1 changelogs are manually written documents and source files.
> A database's (git), temporary meta information is irrelvant.

+1, the changelog is available to the user through an rpm query which is
essential and useful to covey what has has been done.

Ian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Fri, 2011-11-11 at 14:36 +0100, Miloslav Trmač wrote:

> I can see only one difference - starting the daemon from a command
> line within a user's session without double forking would leave the
> process "attached" to the user's session in the process tree; however,
> given that the process was not actually started by the service
> management system in that case, this might arguably be considered a
> correct behavior - and in any case doesn't really matter for anything.

I don't see a problem with automount using a single fork (along with
setsid()), it ends up parented to init just fine. I do however wait for
a status completion in the initial parent so I know that the child has
completed startup.

Ian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Fri, 2011-11-11 at 14:15 +0100, Lennart Poettering wrote:
> On Thu, 10.11.11 11:24, Ian Kent (ra...@themaw.net) wrote:
> 
> > On Wed, 2011-11-09 at 11:01 +, "Jóhann B. Guðmundsson" wrote:
> > > 
> > > Now taking a quick look at the autofs service which I assume you are 
> > > referring too I'm not seeing anykind of massive rewrite in order for the 
> > > daemon ( which generally is an exception that a rule ) to work in 
> > > systemd unit so from a quick and convertion on top of my head while 
> > > writing this, here's a unit file which you can start as your base point 
> > > to work on.
> > > 
> > > ### autofs.service ###
> > > 
> > > [Unit]
> > > Description=Automounts filesystems on demand
> > > Requires=ypbind.service
> > 
> > What happens if ypbind is not installed or is not enabled?
> 
> Requires= pulls in ypbind.service if autofs.service is requested,
> regardless whether the former is enabled or not. If ypbind.service is
> not available, then starting auofs.service will fail.
> 
> If you use Wants= instead here, then we'll still pull in ypbind if
> autofs is requested, but will not fail if ypbind fails, and start autofs
> nonetheless.
> 
> > The problem with this has always been people that use NIS need it to be
> > started before automount but using it is not a requirement since other
> > map sources may be used (and commonly are nowadays) like files or
> > ldap.
> 
> In systemd ordering dependencies and requirement dependencies are fully
> orthogonal. That means After=/Before= can be used independently from
> Requires=/Wants=. You can have either without the other, though most
> often they are used together.
> 
> If all you want to express is that if both ypbind and autofs are enabled
> the latter shall be started after the former, then place an
> After=ypbind.service and that's it. That ensures that autofs does not
> pull in ypbind, but ensures the right ordering if both are pulled in by
> other means.
> 
> > > After=network.target ypbind.service
> > 
> > So maybe this is all that's needed, but how is the conditional ypbind
> > dependency handled?
> 
> After= only has an effect if both units are being started. It's a NOP if
> ypbind.service isn't also started.

OK, so all I really need is an After=, that's good.

> 
> > > [Service]
> > > Type=forking
> > 
> > Right, but the documentation in a previous post talked about a
> > requirement to run in the foreground and log to stdout .
> 
> Hmm? There is no requirement for that.
> 
> It's much nicer if daemons do not double-fork when used within systemd,
> since it simplifies things quite a bit and makes things more robust. But
> that means that your service needs to support some other kind of
> notification to tell systemd when it is fully initialized (for example:
> the sd_notify() API, or by taking a name on the bus), or needs to be
> written in a way that thre's no need to communicate the finished
> initialization to systemd at all (i.e. not listen on any sockets, or
> hand over listening to systemd via socket activation).

I was hoping this would be straight forward.

I have do have a foreground option but I need to encode the log level in
stderr messages which I think will be straight forward as all the
logging code is in a single source file and the log functions are
specific to level.

> 
> > > PIDFile=/run/autofs.pid

What about the pid file.
Do I need to continue to pass the pid file option to autofs or will
systemd do all the pid file handling?

> > > EnvironmentFile=-/etc/sysconfig/autofs
> > 
> > I don't think I need this either and sourcing it in the exiting init
> > file is redundant. The daemon will read the configuration file itself.
> > 
> > > ExecStart=/usr/sbin/automount ${OPTIONS} --pid-file /run/autofs.pid
> > 
> > Oh, except for the daemon start options, mmm, maybe it's time to split
> > the configuration into daemon configuration and init configuration. Is
> > there a better way to do this just for the daemon start options that is
> > easy for users to change?
> 
> My recommendation to simplify things for the user is to have a single
> location for configuration and not split things up between options
> passed on the command line and options configured in a config file.

I agree and that's why we still have a single config file against
complains about having two different types of configuration in the same
location.

Sounds like retaining the sourcing of the config file is the most
sensible option.

> 
> >

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Fri, 2011-11-11 at 14:05 +0100, Lennart Poettering wrote:
> On Thu, 10.11.11 11:07, Ian Kent (ra...@themaw.net) wrote:
> 
> > On Wed, 2011-11-09 at 11:01 +, "Jóhann B. Guðmundsson" wrote:
> > > On 11/09/2011 05:49 AM, Ian Kent wrote:
> > > >>What other form of encouragement can you suggest?
> > > > This email thread for a start.
> > > 
> > > We have had email threads like this for two release cycles now and yet 
> > > the main problem still remains the same packagers/maintainers not either 
> > > migrating themselves or they not packaging submitted unit files...
> > 
> > Thanks for the information on unit files and your efforts to help out,
> > it is much appreciated.
> > 
> > Maybe I'm reading too much into the documentation I read. For example,
> > in automount, I don't do a double fork to disassociate from the tty and
> > haven't used that technique for many years. 
> 
> You aren't? What are you using instead? Note that only double-forking
> will properly detach a process from the parent it is started from on
> Unix, and hence is not an option but mandatory to do -- unless of course
> you are in a systemd environment (or equivalent) which makes the
> detaching redundant since it gives you guarantees about the execution
> context of your service plain SysV does not give you. Please have a look
> at daemon(7) which explains with a check list what daemons need to do on
> SysV to daemonize properly.
> 
> I mean, don't get me wrong, I am happy if people write daemons in the
> new style dropping SysV compatibility cruft. But as I understand you
> that's not actually what you are intending here, right? If you care for
> SysV compat you must double fork.

As far as I know the double fork is a SVR4 requirement and SVR5
functions properly with a single fork/setsid etc.

> 
> > But I also don't have problems with that working properly. Also, I
> > don't believe in the idiocy of attempting to close a thousand or more
> > file descriptors at daemon startup. There's more I got from the link
> > in a previous post to this thread (logging to standard out for
> > example) but this is enough to start with.
> 
> Well, on SysV it's highly recommended to close all open file
> descriptors. On Linux you can do this efficiently by iterating through
> /proc/self/fd. Again, if you don't care for SysV comptat you can skip
> this step, since systemd guarantees you that the only open fds will be
> 0,1,2 and (if configured) any fds passed due to socket activation.

Yes, I know and it may be necessary to do something on this but I don't
see file handle leakage so I don't see the need to change it.

Ian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Wed, 2011-11-09 at 11:01 +, "Jóhann B. Guðmundsson" wrote:
> 
> Now taking a quick look at the autofs service which I assume you are 
> referring too I'm not seeing anykind of massive rewrite in order for the 
> daemon ( which generally is an exception that a rule ) to work in 
> systemd unit so from a quick and convertion on top of my head while 
> writing this, here's a unit file which you can start as your base point 
> to work on.
> 
> ### autofs.service ###
> 
> [Unit]
> Description=Automounts filesystems on demand
> Requires=ypbind.service

What happens if ypbind is not installed or is not enabled?

The problem with this has always been people that use NIS need it to be
started before automount but using it is not a requirement since other
map sources may be used (and commonly are nowadays) like files or ldap.

> After=network.target ypbind.service

So maybe this is all that's needed, but how is the conditional ypbind
dependency handled?

> 
> [Service]
> Type=forking

Right, but the documentation in a previous post talked about a
requirement to run in the foreground and log to stdout .

> PIDFile=/run/autofs.pid
> EnvironmentFile=-/etc/sysconfig/autofs

I don't think I need this either and sourcing it in the exiting init
file is redundant. The daemon will read the configuration file itself.

> ExecStart=/usr/sbin/automount ${OPTIONS} --pid-file /run/autofs.pid

Oh, except for the daemon start options, mmm, maybe it's time to split
the configuration into daemon configuration and init configuration. Is
there a better way to do this just for the daemon start options that is
easy for users to change?

> 
> [Install]
> WantedBy=multi-user.target
> 
> The load module and check section has been drop since loading modules in 
> systemd unit is frowned upon and rightly so since kmods these days can 
> be autoloaded on use and those that cant should drop an conf file for 
> that module load into /etc/modules-load.d/ directory.
> 
> If yours cant be autoloaded on use here's a conf file that loads that 
> module.
> 
> ### autofs.conf ###
> 
> # Load autofs module at boot
> autofs4

Yes, I really need to get around to renaming that module to autofs in
kernel so it can be autoloaded (but that could cause considerable
disruption, it's not straight forward to do in a backward compatible
way). Adding a module load file upstream isn't too appealing since the
module needs to be renamed, maybe this will be Fedora specific.

Lennart, anything to add about or problems you see with this unit
definition?

Ian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Wed, 2011-11-09 at 11:01 +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2011 05:49 AM, Ian Kent wrote:
> >>What other form of encouragement can you suggest?
> > This email thread for a start.
> 
> We have had email threads like this for two release cycles now and yet 
> the main problem still remains the same packagers/maintainers not either 
> migrating themselves or they not packaging submitted unit files...

Thanks for the information on unit files and your efforts to help out,
it is much appreciated.

Maybe I'm reading too much into the documentation I read. For example,
in automount, I don't do a double fork to disassociate from the tty and
haven't used that technique for many years. But I also don't have
problems with that working properly. Also, I don't believe in the idiocy
of attempting to close a thousand or more file descriptors at daemon
startup. There's more I got from the link in a previous post to this
thread (logging to standard out for example) but this is enough to start
with.

Anyway, I think you may not have quite understood what I was tying to
say in my last post. My point was I've been frustrated and annoyed in
the past by init system changes (not necessarily systemd either) so I'm
a hard case to win over.

And that's all I wanted to get across.

Ideally the way this goes is that a new init system, like systemd, is
adopted due to its merits not by forcing people to use it. Sure, it may
be necessary to do some public relations work as time passes to complete
the process but that should work. If that doesn't work then, eventually,
it might be necessary to resort to the heavy handed approach, although,
if that's the case then perhaps the init system isn't really mature
enough.

Don't say we've already done the PR work because it hasn't been done.
Communication to me personally, as the upstream maintainer, never
happened. You also can't expect people to catch all the detail on this
list. Because of the noise level it is way too time consuming when you
have a lot of work to do and other lists to scan.

But the main point here is, even I'm warming to systemd, and that's a
big step for me, given my unpleasant past experience and, consequently,
fairly bad attitude toward init systems.

Ian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Wed, 2011-11-09 at 12:07 +0100, Kay Sievers wrote:
> 2011/11/9 "Jóhann B. Guðmundsson" :
> > On 11/09/2011 05:49 AM, Ian Kent wrote:
> 
> > That only leaves this relevant sections from that quick look that needs
> > some work and remains questionable if that should be handled in unit
> > file et all...
> >
> >   # Check misc device
> > if [ -n "$USE_MISC_DEVICE" -a "x$USE_MISC_DEVICE" = "xyes" ]; then
> > sleep 1
> > if [ -e "/proc/misc" ]; then
> > MINOR=`awk "/$DEVICE/ {print \\$1}" /proc/misc`
> > if [ -n "$MINOR" -a ! -c "/dev/$DEVICE" ]; then
> > mknod -m 0600 /dev/$DEVICE c 10 $MINOR
> > fi
> > fi
> > if [ -x /sbin/restorecon -a -c /dev/$DEVICE ]; then
> > /sbin/restorecon /dev/$DEVICE
> > fi
> > else
> > if [ -c /dev/$DEVICE ]; then
> > rm /dev/$DEVICE
> > fi
> > fi
> >
> 
> Just kill it. The kernel creates the device nodes today, nothing is
> supposed to fiddle around like this in /dev in 2011.

I think that is the right thing to do these days.

It was originally present to allow users to use a configuration option
to force the use of the old style ioctl interface. But using the device
file ioctl interface is much better and has been around for a long time
now.

Ian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Tue, 2011-11-08 at 13:52 +0100, Tomasz Torcz wrote:
> On Tue, Nov 08, 2011 at 01:41:28PM +0100, drago01 wrote:
> > On Mon, Nov 7, 2011 at 8:28 PM, Tomas Mraz  wrote:
> > > On the today's FESCo meeting we discussed the request to move forward
> > > the conversion of the sysvinit scripts to systemd units in Fedora 17.
> > >
> > > The packages which ship sysvinit script but do not ship systemd unit
> > > according to the Fedora packaging guidelines violate this rule:
> > > https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
> > >
> > Such a blocking would be just wrong ... as long as the packages *work*
> > there is no reason to do that.
> > I am all for encouraging maintainers to port there stuff but this is a
> > bit too much.
> 
>   What other form of encouragement can you suggest?

This email thread for a start.

I'm not hurrying to make changes to my package because I've had problems
a couple of times now because of what I consider poor documentation or a
lack of information about where to find documentation. This isn't
specific to systemd at all.

Recent bugs relating to startup problems haven't been worked on because
of ongoing confusion over other init mechanisms and the lack of
assistance in terms of adequate documentation, at least as far as what I
was pointed to.

The documentation link in this thread however is somewhat more useful
but that implies that there is a huge amount of work to do on my daemon
and that will take time. Assuming I do get a pointer to adequate
documentation to unit file construction I'll then start on daemon work.

But don't forget, this is not high priority because the daemon itself
does work OK, except for the startup order dependency difficulties that
have arisen, which weren't introduced by me.

So, to sum up, this thread has encouraged me to look further into
systemd support and a heavy handed approach will not make that go any
faster.

Ian



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] util-linux[-ng] and mtab

[Ian Kent]

On Thu, 2011-01-20 at 09:55 +0100, Karel Zak wrote:
> On Thu, Jan 20, 2011 at 02:08:50PM +0800, Ian Kent wrote:
> > On Wed, 2011-01-19 at 18:35 +0100, Karel Zak wrote:
> > > I have pushed new util-linux into rawhide. The project has been
> > >  renamed from util-linux-ng back to util-linux.
> > > 
> > >  The util-linux v2.19-rc1 contains support for systems without
> > >  /etc/mtab (the file is replaced with symlink to /proc/mounts). 
> > >  This feature is enabled by default on Fedora (due to systemd).
> > > 
> > >  If your system depends on regular mtab then you can remove the
> > >  symlink -- mount(8) still supports old mtab too.
> > 
> > Once again I say, what about mount entries that should not be reported
> > against by utilities that look at the mount table?
> 
>  Ideally there is only one mount table -- in kernel. Every other mount
>  table sucks, because:
> 
> - kernel supports namespaces
> - everyone can call mount(2) syscall independently on mount(8)
> - exclusive write access to userspace mount table is performance
>   problem (e.g. mtab lockig)
> - mtab mount options don't match with real kernel options
> - etc.
> 
>  So, our goal is to minimize number of situations where userspace
>  mount options are required.

I'm not arguing against this at all.
I'm just saying we must have a bit of co-ordination.

Although I had in mind something similar to mounting an individual file
rather than using a file within a file system. OTOH, it's already
available for use.

>  
>  For backward compatibility and for some special cases (e.g. uhelper=,
>  or NFS) libmount maintains userspace mount options, but there is no
>  reason to care about all options for all entries. 
> 
>  I hope that the user= option will be handled by kernel (by fsuid in
>  /proc/mounts) one day.
> 
>  The another solution is to store more information to kernel, but this
>  has to be individually handled by FS drivers, any generic solution 
>  for userspace options in kernel is not planned.
> 
> > I can tell you from experience with old versions of AIX that without
> > something in the mount table to allow utilities to ignore mount entries
>   ^^
>  What exactly? Special mount options, tags?

Yeah, in Solaris all autofs mounts have a pseudo option to tell
utilities not to include them in their reports.

I can't remember now what it was in Solaris but it was something like
"ignore". It would be easy to add an option to such mounts in the the fs
super_operations .show_options method. Then no user space changes would
be needed to make it appear, but then we are stuck with the "this works
in kernels later than " problem.

The crucial thing is that utilities maintainers be on board with however
this is done for it to work.

> 
> > when appropriate, as is done in Solaris, these utilities is just about
> > unusable.
> 
>  findmnt(8) allows to browse mount tables (kernel, mtab, fstab).
> 
>  Now it supports select/ignore entries by FS type, mount options,
>  mount point (target), spec (source). Suggestions and feature requests
>  are welcomed.

So, maybe all we really need is for utilities maintainers to use this
feature. Not sure what's best and there clearly needs to be some
discussion about when to leave such things as autofs file system mounts
out. For example cat  needs to always show
the real contents of the mount table while calling mount(8) shouldn't.

> 
>  For example:
> 
>  $ findmnt | wc -l
>  32
> 
>  $ findmnt -t noautofs | wc -l  
>  27
> 
> Karel
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] util-linux[-ng] and mtab

[Ian Kent]

On Wed, 2011-01-19 at 18:35 +0100, Karel Zak wrote:
> I have pushed new util-linux into rawhide. The project has been
>  renamed from util-linux-ng back to util-linux.
> 
>  The util-linux v2.19-rc1 contains support for systems without
>  /etc/mtab (the file is replaced with symlink to /proc/mounts). 
>  This feature is enabled by default on Fedora (due to systemd).
> 
>  If your system depends on regular mtab then you can remove the
>  symlink -- mount(8) still supports old mtab too.

Once again I say, what about mount entries that should not be reported
against by utilities that look at the mount table?

I can tell you from experience with old versions of AIX that without
something in the mount table to allow utilities to ignore mount entries
when appropriate, as is done in Solaris, these utilities is just about
unusable.

Ian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /etc/mtab

[Ian Kent]

On Thu, 2010-12-23 at 12:12 +0100, Lennart Poettering wrote:
> On Wed, 22.12.10 22:38, Bernie Innocenti (ber...@codewiz.org) wrote:
> 
> > What's preventing us from symlinking /etc/mtab to /proc/mounts and get
> > rid of confusing situations when mtab gets out of sync with the
> > kernel?
> 
> Some of the mount options that /bin/mount uses currently are seen by
> userspace only and cannot be attached to the mount point in-kernel. The
> effect of that is that if you symlink /etc/mtab to /proc/mounts these
> options get silently dropped after mount, and while they might have
> effect at mount time, afterwards (i.e. umount time) they will have zero
> effect. An example of such an option is "user" and "users".
> 
> It is definitely planned to get rid of /etc/mtab, but before that
> happens the kernel must either learn to store userspace mount options
> along kernel mount options for each mount point in some way (Miklos
> Szeredi has been working on this IIRC), or /bin/mount must learn to
> store these options somewhere in userspace (for example /dev/.mount or
> so), and then augment its output with these options. (Karel Zak has been
> thinking about adding this).

And lets not forget the need for a pseudo mount option that can be used
by the user space tools to ignore certain mounts, such as autofs mounts.

> 
> Sooner or laer we will definitely make /etc/mtab a symlink, which should
> take us one definite step nearer to supporting r/o root by default. 
> 
> In fact, in systemd we already warn during boot if /etc/mtab is not a
> symlink, and we do not longer clear that file on bootup, all to put a
> tiny bit of pressure on the folks involved to fix this properly once and
> for all, in the F15 timeframe...
> 
> > I tried running my system for a few months this way. The only
> > regressions I'm seeing are:
> > 
> > 1) the Gnome Disk Mounter panel applet seems to get confused. After a
> > loopback mount gets unmounted, there's still an icon to remount the
> > device. (the loopback device is correctly cleaned up at umount time).
> 
> Loop devices use userspace-only mount options too, afair.
> 
> > 2) on boot, the system tries to remount /sys even though it's already
> > mounted, thus spitting this harmless error:
> > 
> > Remounting root filesystem in read-write mode: [  OK  ]
> > mount: according to mtab, /dev/sda1 is already mounted on /
> > Mounting local filesystems:  mount: sysfs already mounted or /sys busy
> > mount: according to mtab, /sys is already mounted on /sys [FAILED]
> > Enabling /etc/fstab swaps: [  OK  ]
> 
> This problem is gone on F15/Rawhide anyway, since systemd mounts this dir.
> 
> Lennart
> 
> -- 
> Lennart Poettering - Red Hat, Inc.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2

[Ian Kent]

On 01/13/2010 09:07 AM, Tom Lane wrote:
> Lennart Poettering  writes:
>> if you have code that links against libxml2 and calls
>> xmlCleanupParser() please verify that your project does that at the
>> appropriate place (i.e. immediately before exiting, and only once).
> 
> Why exactly is this a misuse, and not libxml2's bug to fix?  There's
> certainly nothing in their documentation suggesting that there's
> such a requirement.

libxml2 also doesn't use pthreads Thread Specific Keys correctly either
which can lead to segv if the library is unloaded prior to the threaded
application exiting.

Ian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel