[Freeipa-users] Re: group management on freeipa clients
So. this is an interesting read thanks for that. But just a FYI to the OP, if you are using any Ubuntu 18.04 clients (i haven’t tried it with Fedora/CentOS) there is an issue with not having local docker groups on the system. What ends up happening is on a boot, docker services try starting up, but look for a local docker group when they do. If there is no docker group the service times out. When the machine does finally boot up, DNS resolution for some reason is broken. Networking works fine (e.g can ping 8.8.8.8 or any local ip). But without DNS resolution the machine won’t properly find the IPA server and won’t allow users to login. Docker made this service change from 16.04 to 18.04. Here I detailed how I determined what the issue was. I put in another ticket with this information but was told it wasn’t an issue with docker. https://github.com/docker/libnetwork/issues/2335 -Kevin > On Oct 24, 2019, at 6:18 PM, Simo Sorce via FreeIPA-users > wrote: > > I strongly recommend reading this article: > https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/ > > And based on it, I would a) reconsider if using sudo is not a better > idea, b) recommend, if possible, to create the docker group locally and > add users explicitly on the specific machines. > > I would fallback to a global docker group that basically gives root to > any user on any machine with docker installed they have access to only > as a least resort. > > Simo. > >> On Wed, 2019-10-23 at 19:07 +, Jason Dunham via FreeIPA-users >> wrote: >> Hi I'm trying to figure out the best practice for groups on my client >> servers. >> I have several computation workstation hosts that have been added as freeipa >> clients, and several engineers who want to run docker on them >> Members of the 'docker' group (gid=999 on some machines, for example) can >> run docker without needing sudo, which is what I want to roll out to all >> machines. Ideally this would be managed from freeipa with LDAP groups, and >> so anyone in the 'engineers' group should also be a member of the 'docker' >> group. >> When I create a 'docker' group on freeIPA it will have some other gid and >> the client sees that. >> Should I just delete the original docker group from my hosts and let it get >> it from ldap, or should I go into /etc/group and change the gid to the one >> that matches the right ldap gid, or preferably something easier than that? >> ___ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: group management on freeipa clients
I strongly recommend reading this article: https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/ And based on it, I would a) reconsider if using sudo is not a better idea, b) recommend, if possible, to create the docker group locally and add users explicitly on the specific machines. I would fallback to a global docker group that basically gives root to any user on any machine with docker installed they have access to only as a least resort. Simo. On Wed, 2019-10-23 at 19:07 +, Jason Dunham via FreeIPA-users wrote: > Hi I'm trying to figure out the best practice for groups on my client servers. > I have several computation workstation hosts that have been added as freeipa > clients, and several engineers who want to run docker on them > Members of the 'docker' group (gid=999 on some machines, for example) can run > docker without needing sudo, which is what I want to roll out to all > machines. Ideally this would be managed from freeipa with LDAP groups, and > so anyone in the 'engineers' group should also be a member of the 'docker' > group. > > When I create a 'docker' group on freeIPA it will have some other gid and the > client sees that. > Should I just delete the original docker group from my hosts and let it get > it from ldap, or should I go into /etc/group and change the gid to the one > that matches the right ldap gid, or preferably something easier than that? > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: ssh ProxyCommand in ipa-client causes crash of x2goclient
On to, 24 loka 2019, Kees Bakker via FreeIPA-users wrote: Hey, With x2go [1] you can start a remote desktop. Going from UNIX (client) to UNIX (server) it will use SSH behinds the scenes. However, on a IPA client the x2goclient command fails with a segfault (somewhere in a ssh library). This is caused by the modified /etc/ssh/ssh_config. More specifically this ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h When you disable this line the x2go connection succeeds. [1] https://wiki.x2go.org/doku.php If you could install debug packages and generate a backtrace, that would be great as it would help to understand where it happens. Thanks in advance! -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] ssh ProxyCommand in ipa-client causes crash of x2goclient
Hey, With x2go [1] you can start a remote desktop. Going from UNIX (client) to UNIX (server) it will use SSH behinds the scenes. However, on a IPA client the x2goclient command fails with a segfault (somewhere in a ssh library). This is caused by the modified /etc/ssh/ssh_config. More specifically this ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h When you disable this line the x2go connection succeeds. [1] https://wiki.x2go.org/doku.php -- Kees ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: valid hostname?
On ke, 23 loka 2019, François Cami via FreeIPA-users wrote:
On Wed, Oct 23, 2019 at 10:31 PM Amos via FreeIPA-users
wrote:
When enrolling a host, an error was presented:
root: INFO Joining realm failed: RPC failed at server. invalid
'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS
label may not start or end with '-'
Where does this error originate from? Is it truly impossible to allow hosts with
"_" in their name?
The way I read https://tools.ietf.org/html/rfc1035 and
https://tools.ietf.org/html/rfc952 makes underscores invalid there.
Esp. from RFC1035:
"When creating a new host name, the old rules for HOSTS.TXT should be followed."
"The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less."
RFC952 never mentions underscores.
Underscore was banned originally because the keyboard of the Teletype
ASR-33 had no underscore button. Being a very common terminal at the
time of RFC606/608 creation, it was impractical to have underscore in
it.
We need to differentiate Internet host names and DNS itself. DNS itself is a
database to put any kind of data, not only Internet host names.
A key RFC here is RFC2181, Clarifications to the DNS specification. It
states in section 11 (https://tools.ietf.org/html/rfc2181#section-11):
The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators). The zero
length full name is defined as representing the root of the DNS tree,
and is typically written and displayed as ".". Those restrictions
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used. In particular, DNS servers must not
refuse to serve a zone because it contains labels that might not be
acceptable to some DNS client programs. A DNS server may be
configurable to issue warnings when loading, or even to refuse to
load, a primary zone containing labels that might be considered
questionable, however this should not happen by default.
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose
whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values
returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.
See also [RFC1123] section 6.1.3.5.
RFC1123 section 6.1.3.5 has this:
The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets. Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names. In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].
It refers to RFC1123 section 2.1:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
Underscore was never allowed to be used in
