sudo not looking into /usr/local
by Samuel Rakitničan
Hi,
Something I stumbled upon today is that there is no convenient way by default to make some custom script accessible via sudo without specifying full path. Found out that sudo have limited set of paths in its environment that is looking into [1]. Sadly, none of it is appropriate for custom scripts. I think it would be nice to include /usr/local/bin and /usr/local/sbin also.
[1] http://unix.stackexchange.com/a/8652
7 years, 5 months
Orphan package: webalizer
by Joe Orton
This thing is not actively maintained upstream; no intent to carry this
any more.
Regards, Joe
7 years, 5 months
GitPython update blocked by rpkg - how can this be resolved?
by Barry
In this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1360797
It is implied that rpkg has an unspecified problem with GitPython 2.0.
This is preventing the maintainer from updating to the any GitPython 2
release.
I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.
If there is a problem it would be nice if the rpkg people could comment on the
difficult of supporting GitPython 2. The python2.6 support question I suspect
can be handled by version checking in any conflicting code.
It seems wrong that rpkg is blocking updating to the latest GitPython,
preventing user of GitPython getting the bugs fixes and (as far as I am aware)
backwards compatible improvements.
Barry
7 years, 5 months
Re: Broken dependencies: wildfly
by gil
hi
see https://bodhi.fedoraproject.org/updates/FEDORA-2016-a04534101f
regards
.g
Il 15/11/2016 15:02, buildsys(a)fedoraproject.org ha scritto:
> wildfly has broken dependencies in the F-25 tree:
> On x86_64:
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hibernate:hibernate-search-infinispan)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hornetq:hornetq-amqp-protocol)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-lucene-v3)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-query)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.security:jboss-negotiation-net)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
> On i386:
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hibernate:hibernate-search-infinispan)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hornetq:hornetq-amqp-protocol)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-lucene-v3)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-query)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.security:jboss-negotiation-net)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
> On armhfp:
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hibernate:hibernate-search-infinispan)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.hornetq:hornetq-amqp-protocol)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-lucene-v3)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.infinispan:infinispan-query)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.security:jboss-negotiation-net)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
> wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
> Please resolve this as soon as possible.
>
>
>
7 years, 5 months
RFC (round 2): Change the default hostname for Fedora 26+
by Stephen Gallagher
The original thread is getting rather long and I'd like to attempt to summarize
the discussion thus far and see if we can find a way forward from there.
First, some clarifications for preconditions that some people were unaware of
(either on this thread or the ones that popped up on other lists/forums):
1) Fedora has always allowed the hostname to be changed in Anaconda. It's
perhaps not in the most obvious of places (the networking spoke), but it's
there. It can also be set via kickstart, of course.
2) The default today is to use a name provided by the DHCP server if it offers a
name for that device, otherwise it will fall back to localhost.localdomain (the
common case for most personal networks).
3) My original proposal was: change the fallback name to Fedora-XXXXXXXX by
default, while of course retaining the ability to set it manually.
4) The specific issue relating to FreeIPA and Active Directory is one of
uniqueness: you can only have one machine named "localhost" enrolled in a
domain. A user who is unaware of the hostname at all will not know to change it
ahead of time.
The thread on Fedora Devel revealed some other issues which need to be
considered carefully. One of these is that of privacy: for example, the DHCP
client will send the machine's hostname as one of the cues to the DHCP server
for acquiring a lease. While this is fine on private networks, there's a valid
concern that this might be undesirable on a public hotspot. (This is only one
such example; there may be other places where the system transmits the hostname).
With machines commonly defaulting to localhost.localdomain, getting this
information tells the recipient little more than that a Fedora-derived machine
is connecting (since it's the only known ecosystem that uses this specific
default). However, the more unique we make the name, the easier it becomes to
isolate it to a single system (such as for tracking purposes). It is an open
question whether this is an actual problem to worry about or whether it's a drop
in the proverbial bucket.
It's also worth noting of course that any manually-chosen hostname will have
this same problem, which begs the question of whether it's worthwhile to do
anything about it at all. (Or perhaps that the focus should be on not leaking
the hostname itself elsewhere, regardless of how it was created).
I hope this frames the discussion better.
My thoughts from here:
The hostname may always be set manually and the result will (for the vast
majority of people) be unique within their environment. This means that if we
are concerned with hostname leakage being a privacy issue, we need to address
that at the leakage point, not at the hostname point.
Also, there are cases where hostname leakage may be used specifically *because*
it may be unique, such as one of several cues to the DHCP server. Unfortunately,
we cannot know in advance whether a DHCP server is going to be on a trusted or
untrusted network (we might be able to guess from the SSID of a WiFI connection,
but those are remarkably easy to fake).
In short, I really don't think that the hostname is the right place to solve
this problem. If transmission of individually-identifying information is a
concern, then we really have to solve it at the transmission points and not at
the source.
Yes, an argument could be made that a user who sets her own hostname is
"opting-in" to that uniqueness, but I think that's setting an unrealistic
expectation on all of our users that they fully understand the consequences of
that action.
Further, from a purely technical perspective, I think I've been swayed by
arguments around the generation of the hostname:
* I'm fine with the lowercase "fedora-" prefix. It makes sense since hostnames
are generally normalized to lower-case in common usage.
* I like Zbigniew and Lennart's thoughts on how to generate the "random" suffix.
the implementation I'd likely use is to take the first eight characters of an
md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
repeatable and unique.
For Anaconda folks: would it be possible to have the currently-selected hostname
be visible next to the "Networking" spoke on the main hub page? You show the
selected environment group beside the "Software Selection" spoke and the
connected network device, so it might be useful to let people know what the
hostname is as well. (This would also be handy if it turns out that DHCP is
trying to assign a hostname; the user may not want or expect that)
7 years, 5 months