[Freeipa-users] POSIX attributes and Trusts in FreeIPA

2021-03-10 Thread Lachlan Musicman via FreeIPA-users
Can I please get clarification on a FreeIPA instance (as IdM in RHEL8.3) and 
AD's POSIX attributes?

From what I can see, the POSIX attributes - are ignored?

Specifically, when I run 

$ id u...@ad.domain.com
$ id -u u...@ad.domain.com
$ id -g u...@ad.domain.com

The POSIX attribute values are not being returned. I am getting a correct list 
of AD groups etc, which is great. But no POSIX attributes. Do I need to 
explicitly request those attributes?

I note that there is an article from 2017 (1) "Configuring an Active Directory 
Domain with POSIX Attributes" which declares itself deprecated for (2) "Chapter 
8. Using ID Views in Active Directory Environments", which is RHEL7. From what 
I can see both of these are about direct attachment to AD rather than for use 
in an IPA instance (although they reference IdM) 

It looks like AD side POSIX attributes are only available to direct integration 
and even then only when specifically installed with realm (direct integration) 
and  --automatic-id-mapping=no (3)


(1) https://access.redhat.com/articles/3023821
(2) 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/id-views
(3) 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/connecting-rhel-systems-directly-to-ad-using-sssd_integrating-rhel-systems-directly-with-active-directory#using-posix-attributes-defined-in-active-directory_connecting-directly-to-ad


Cheers
L.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: ipa-idoverride-memberof-plugin issue, ipa 4.8.7 rhel 8.3

2020-12-10 Thread Lachlan Musicman via FreeIPA-users
Perfect, thank you. 
___
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] ipa-idoverride-memberof-plugin issue, ipa 4.8.7 rhel 8.3

2020-12-09 Thread Lachlan Musicman via FreeIPA-users
Hola,

When I browse to the webUI for IDM, I'm getting nothing.

The http error log is showing:

[Thu Dec 10 15:30:44.429646 2020] [wsgi:error] [pid 1773:tid 139794280646400] 
[remote 172.26.33.93:42908] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.239'): SUCCESS
[Thu Dec 10 15:32:28.088766 2020] [wsgi:error] [pid 1773:tid 139794280646400] 
[remote 172.26.33.93:42932] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.239'): SUCCESS
[Thu Dec 10 15:32:39.316974 2020] [wsgi:error] [pid 1773:tid 139794280646400] 
[remote 172.26.33.93:42932] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.239'): SUCCESS
[Thu Dec 10 15:32:53.657573 2020] [wsgi:error] [pid 1774:tid 139794280646400] 
[remote 172.26.33.93:42932] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.239'): SUCCESS

The http access log is more interesting:

172.26.33.93 - - [10/Dec/2020:15:32:53 +1100] "GET 
/ipa/ui/js/plugins/idoverride-memberof/idoverride-memberof.js?40807 HTTP/1.1" 
404 19

When I go hunting, I see this:

[root@idm httpd]# ls -la /usr/share/ipa/ui/js/plugins/idoverride-memberof/
total 0
drwxr-xr-x. 2 root root  6 Dec 10 13:36 .
drwxr-xr-x. 3 root root 33 Oct  9 00:45 ..

I see there is a package available;

[root@idm httpd]# dnf info ipa-idoverride-memberof-plugin --all
...
Available Packages
Name : ipa-idoverride-memberof-plugin
Version  : 0.0.4
Release  : 6.module+el8+2555+b334d87b
Architecture : x86_64
Size : 31 k
Source   : ipa-idoverride-memberof-0.0.4-6.module+el8+2555+b334d87b.src.rpm

But I see that it's already installed:

Package ipa-server-trust-ad-4.8.7-13.module+el8.3.0+8376+0bba7131.x86_64 is 
already installed.

I updated from RHEL 8.2 to 8.3 this AM. It was working last week with 8.2. Is 
there meant to be an idoverride-memberof.js file?

cheers
L.
___
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: How to delete replica that no longer exists?

2018-10-21 Thread Lachlan Musicman via FreeIPA-users
On Wed, 3 Oct 2018 at 09:28, Lachlan Musicman  wrote:

> On Wed, 3 Oct 2018 at 08:34, Lachlan Musicman  wrote:
>
>> How do I delete a replica from the master if the replica no longer exists?
>>
>> The message I get is "Unable to delete replica hostname; cannot connect
>> to ldaps://hostname:389"
>>
>
> I tried using --force but got
>
> $ ipa-csreplica-manage del hostname --force -v
>


Ah!

ipa-replica-manage del hostname --force --cleanup

Seems to have worked - via
https://github.com/freeipa/freeipa-container/issues/40

cheers
L.
___
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://getfedora.org/code-of-conduct.html
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: Testing requested - certificate checking tool

2018-10-04 Thread Lachlan Musicman via FreeIPA-users
On Thu, 4 Oct 2018 at 23:22, Rob Crittenden via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> As part of a larger IPA "health" checker and driven largely by necessity
> I have the beginning of a certificate checking tool available at
> https://github.com/rcritten/checkcerts
>
> It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+
> patches). YMMV.
>

I ran this on CentOS 7.5 with IPA 4.5.0 and it worked for me - I've sent
the output to Rob.

I got one error that I don't know how to fix -

Unknown certmonger ids: 20170919231606

What's the process for either removing or making it known?

Cheers
L.

---
Kathi Weeks, *The Problem with Work: Feminism, Marxism, Antiwork Politics
and Postwork Imaginaries*

___
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://getfedora.org/code-of-conduct.html
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: How to delete replica that no longer exists?

2018-10-02 Thread Lachlan Musicman via FreeIPA-users
On Wed, 3 Oct 2018 at 08:34, Lachlan Musicman  wrote:

> How do I delete a replica from the master if the replica no longer exists?
>
> The message I get is "Unable to delete replica hostname; cannot connect to
> ldaps://hostname:389"
>

I tried using --force but got

$ ipa-csreplica-manage del hostname --force -v
Directory Manager password:

Unable to connect to replica hostname, forcing removal
Failed to get data from 'hostname': cannot connect to
'ldap://hostname:389':
Forcing removal on 'hostname'
There were issues removing a connection: 'NoneType' object has no attribute
'port'

Hmm.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


[Freeipa-users] How to delete replica that no longer exists?

2018-10-02 Thread Lachlan Musicman via FreeIPA-users
How do I delete a replica from the master if the replica no longer exists?

The message I get is "Unable to delete replica hostname; cannot connect to
ldaps://hostname:389"

cheers
L.

--
'...postwork futures are dismissed with the claim that "it is not in our
nature to be idle", thereby demonstrating at once an essentialist view of
labor and an impoverished imagination of the possibilities of nonwork.'

Kathi Weeks, *The Problem with Work: Feminism, Marxism, Antiwork Politics
and Postwork Imaginaries*

___
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://getfedora.org/code-of-conduct.html
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: FreeIPA AD Trust with Samba4 ... is it possible?

2018-08-13 Thread Lachlan Musicman via FreeIPA-users
On 14 August 2018 at 01:38, Hacker Sword via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi Alex,
>
> >The documentation is only conflicting if you are using it in a
> conflicting way.
>
>
> > The choice of Kerberos library is important. Samba AD DC with MIT
> Kerberos still is broken regarding trust to FreeIPA.
>
> Pardon my ignorance, I am just going by the documentation as is w/ no
> prior knowledge ... where in the documentation is that specified?
> The two main documentation pages I see when googling "freeipa AD trust"
> are:
>
> https://www.freeipa.org/page/Active_Directory_trust_setup
> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
>


I believe that the canonical documentation for FreeIPA is now the RedHat 7
documentation. These two very elegant URLs are the best documentation at
the moment:

https://access.redhat.com/articles/1586893

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index

Cheers
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/TB5GZO6UGQKXMMIXGDFYRXRALDL3G2ZO/


[Freeipa-users] Re: DNS not resolving IPA Clients or IPA Server

2018-07-10 Thread Lachlan Musicman via FreeIPA-users
On 11 July 2018 at 14:39, Sameer Gurung via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> my IPA server is linserver. IP: 192.168.0.111
> domain is dcs.smcs
>
> on my client machine /etc/resolv.conf
> namserver 192.168.0.111
>
> when i dig linserver.dcs.smcs
>
> I get no result. ANSWER 0
>
> am on ipa server 4.5 on cent os 7
>
> the firewall allows DNS requests. port 53, 80, 443 open for tcp and udp
>

Sameer,

That ip address 192.168.0.111 is a private address, so I presume you are on
an internal network.

The resolve.conf on the client has a spelling error - it should be

nameserver 192.168.0.111

Fix that and try again?

Note that CentOS will overwrite /etc/resolv.conf everytime you reboot.
Google CentOS or RedHat resolv.conf to find a number of solutions to that
issue.

Cheers
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/LWE6VZJXA4B67PYYI4TBOJPTGM3N7WJO/


[Freeipa-users] Re: Replica can ipa-find but can't id

2018-06-18 Thread Lachlan Musicman via FreeIPA-users
On Mon., 18 Jun. 2018, 16:15 Alexander Bokovoy,  wrote:

> On ma, 18 kesä 2018, Lachlan Musicman wrote:
> >On 15 June 2018 at 16:03, Alexander Bokovoy  wrote:
> >
> >> On pe, 15 kesä 2018, Lachlan Musicman via FreeIPA-users wrote:
> >>
> >>>
> >>> https://github.com/freeipa/freeipa/pull/1825
> >>>
> >>> And from here
> >>> https://lists.fedorahosted.org/archives/list/freeipa-users@
> >>> lists.fedorahosted.org/thread/RLWBXYP6PPHGXMJZZNEAO6TF7BCB6EDS/
> >>>
> >>> it looks like I need to run
> >>>
> >>> ipa-adtrust-install --add-agents
> >>>
> >>> on the master and follow the prompts?
> >>>
> >> Exactly.
> >>
> >>
> >
> >Alex, thanks for the confirmation.
> >
> >FWIW, running ipa-adtrust-install --add-agents on the current ipa master
> >asked me:
> >
> >WARNING: 1 IPA masters are not yet able to serve information about users
> >from trusted forests.
> >Installer can add them to the list of IPA masters allowed to access
> >information about trusts.
> >If you choose to do so, you also need to restart LDAP service on those
> >masters.
> >Refer to ipa-adtrust-install(1) man page for details.
> >
> >IPA master [ipa-replica.company.com]? [no]:
> >
> >which, when I said no, exited without making any changes that I could see.
> When you run ipa-adtrust-install --add-agents on existing trust
> controller, it asks you whether you want to convert *another* IPA master
> to a trust agent.
>
> This is what you should do if you only want to have that *another* IPA
> master as a trust agent. So you needed to answer 'yes' there.
>
>
> >When I ran same on the replica, I got the same question, but this time
> >answered yes. I can now id users successfully - but fwiw, when I run
> This converted the replica to trust controller, not trust agent.
>
> >So it has become a trust controller as well.
> Yes, because you asked it to do so by running ipa-adtrust-install on it.
>
> >Is that because it's also a CA server?
> No. It is because you asked it to become a trust controller by runnning
> ipa-adtrust-install on the host.
>
> If you want to make a replica a trust agent, run ipa-adtrust-install
> --add-agents on _existing_ trust controller
>

Ok. Thank you.

Is it an issue to have two trust controllers?

If it is, is there an easy way to remove trust controller status?

Cheers
L.

>
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Y2JCOLTBI52LVVO653YE3F4I3VFK2YCF/


[Freeipa-users] Re: Replica can ipa-find but can't id

2018-06-17 Thread Lachlan Musicman via FreeIPA-users
On 15 June 2018 at 16:03, Alexander Bokovoy  wrote:

> On pe, 15 kesä 2018, Lachlan Musicman via FreeIPA-users wrote:
>
>>
>> https://github.com/freeipa/freeipa/pull/1825
>>
>> And from here
>> https://lists.fedorahosted.org/archives/list/freeipa-users@
>> lists.fedorahosted.org/thread/RLWBXYP6PPHGXMJZZNEAO6TF7BCB6EDS/
>>
>> it looks like I need to run
>>
>> ipa-adtrust-install --add-agents
>>
>> on the master and follow the prompts?
>>
> Exactly.
>
>

Alex, thanks for the confirmation.

FWIW, running ipa-adtrust-install --add-agents on the current ipa master
asked me:

WARNING: 1 IPA masters are not yet able to serve information about users
from trusted forests.
Installer can add them to the list of IPA masters allowed to access
information about trusts.
If you choose to do so, you also need to restart LDAP service on those
masters.
Refer to ipa-adtrust-install(1) man page for details.

IPA master [ipa-replica.company.com]? [no]:

which, when I said no, exited without making any changes that I could see.

When I ran same on the replica, I got the same question, but this time
answered yes. I can now id users successfully - but fwiw, when I run

Server name: ipa-replica.company.com
  Server name: ipa-replica.company.com
  Managed suffixes: domain, ca
  Min domain level: 0
  Max domain level: 1
  Enabled server roles: CA server, NTP server, AD trust agent, AD trust
controller

So it has become a trust controller as well.

Is that because it's also a CA server?

cheers
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ICED7RV7UHN5H6H2HJ5JFTUQRDNSXAFO/


[Freeipa-users] Replica can ipa-find but can't id

2018-06-14 Thread Lachlan Musicman via FreeIPA-users
CentOS 7.5
ipa --version VERSION: 4.5.4, API_VERSION: 2.228

When on my replica, and I use

ipa idoverrideuser-find 'Default Trust View'  I get the expected
results:

--
1 User ID override matched
--
  Anchor to override: :SID:S-1-5-21-55386287-1424373824-1154838474-51686
  User login: 
  UID: 1503
  GECOS: User Name
  GID: 1503
  Home directory: /home/uname
  Login shell: /bin/bash

Number of entries returned 1


But when I do

id 

I get

id: uname: no such user


What have I done wrong?

I've also seen the error listed on this thread - could it be that my
replica is not a trust agent?

https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/6LDXSQW5H3CE44CVXPMK53FOMG4LBGYN/

Having read

https://bugzilla.redhat.com/show_bug.cgi?id=1206613
and
https://pagure.io/freeipa/issue/7410

I see that I can test this

[root@ipa-replica ~]# ipa server-show
Server name: ipa-master.company.com
  Server name: ipa-master.company.com
  Managed suffixes: domain, ca
  Min domain level: 0
  Max domain level: 1
  Enabled server roles: CA server, NTP server, AD trust agent, AD trust
controller
[root@ipa-replica ~]# ipa server-show
Server name: ipa-replica.company.com
  Server name: ipa-replica.company.com
  Managed suffixes: domain, ca
  Min domain level: 0
  Max domain level: 1
  Enabled server roles: CA server, NTP server

It's not a trust agent or controller. I presume it should be? Yes, having
now read to the end of ticket 7410 I see that I should have set the replica
up with --setup-adtrust

https://github.com/freeipa/freeipa/pull/1825

And from here
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/RLWBXYP6PPHGXMJZZNEAO6TF7BCB6EDS/

it looks like I need to run

ipa-adtrust-install --add-agents

on the master and follow the prompts?



L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/6JYX3XSTQNDHERTTIGRDYTZYPNSE2FBJ/


[Freeipa-users] Re: FreeIPA upgrade fails in CentOS 7.4 to CentOS 7.5 upgrade

2018-06-05 Thread Lachlan Musicman via FreeIPA-users
On 6 June 2018 at 11:24, Lachlan Musicman  wrote:

> From ipaupgrade.log, the CA isn't coming up?
>


Digging, I found this

Internal Database Error encountered: Could not connect to LDAP server host
vmpr-linuxidm.unix.company.com port 636 Error netscape.ldap.LDAPException:
Unable to create socket: java.net.ConnectException: Connection refused
(Connection refused) (-1)

I think it was in the pki logs?

So tomcat wont start (according to ipactl, it's started according to
sysctl), same for pki-tomcat and dirsrv.

I've had to revert to last night's backup as this is required
infrastructure. My updates of the other servers I use as dev worked fine in
centos 7.4 -> 7.5 eventually. I can't recall but I think it was just a
reboot and ipa-server-upgrade and it was fine.

hmmm
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ATB436YOH3CFNJ7PHTW6V7N2E6AIU5F5/


[Freeipa-users] FreeIPA upgrade fails in CentOS 7.4 to CentOS 7.5 upgrade

2018-06-05 Thread Lachlan Musicman via FreeIPA-users
>From ipaupgrade.log, the CA isn't coming up?


2018-06-06T01:05:40Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 300
2018-06-06T01:05:40Z DEBUG waiting for port: 8080
2018-06-06T01:05:40Z DEBUG Failed to connect to port 8080 tcp on ::1
2018-06-06T01:05:40Z DEBUG Failed to connect to port 8080 tcp on 127.0.0.1
2018-06-06T01:05:41Z DEBUG SUCCESS: port: 8080
2018-06-06T01:05:41Z DEBUG waiting for port: 8443
2018-06-06T01:05:41Z DEBUG Failed to connect to port 8443 tcp on ::1
2018-06-06T01:05:41Z DEBUG Failed to connect to port 8443 tcp on 127.0.0.1
2018-06-06T01:05:42Z DEBUG SUCCESS: port: 8443
2018-06-06T01:05:42Z DEBUG Waiting until the CA is running
2018-06-06T01:05:42Z DEBUG request POST
http://vmpr-linuxidm.unix.company.com:8080/ca/admin/ca/getStatus
2018-06-06T01:05:42Z DEBUG request body ''
2018-06-06T01:05:46Z DEBUG response status 500
2018-06-06T01:05:46Z DEBUG response headers Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 2208
Date: Wed, 06 Jun 2018 01:05:46 GMT
Connection: close

2018-06-06T01:05:46Z DEBUG response body 'Apache
Tomcat/7.0.76 - Error report
HTTP Status 500 - Subsystem unavailabletype Exception reportmessage
Subsystem unavailabledescription The server
encountered an internal error that prevented it from fulfilling this
request.exception
javax.ws.rs.ServiceUnavailableException: Subsystem
unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:500)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\nnote
The full stack trace of the root cause is available in the Apache
Tomcat/7.0.76 logs.Apache
Tomcat/7.0.76'
2018-06-06T01:05:46Z DEBUG The CA status is: check interrupted due to
error: Retrieving CA status failed with status 500
2018-06-06T01:05:46Z DEBUG Waiting for CA to start...
2018-06-06T01:05:47Z DEBUG request POST
http://vmpr-linuxidm.unix.company.com:8080/ca/admin/ca/getStatus
2018-06-06T01:05:47Z DEBUG request body ''
2018-06-06T01:05:47Z DEBUG response status 500
2018-06-06T01:05:47Z DEBUG response headers Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 2208
Date: Wed, 06 Jun 2018 01:05:47 GMT
Connection: close




I found some old bugs that don't seem to apply, like this one

https://bugzilla.redhat.com/show_bug.cgi?id=1318616

and some that do
https://pagure.io/freeipa/issue/6766

Doesn't actually fix the problem that my users can't login :/

Gah, I thought this had been fixed - it was in my upgrade of the dev server

L.






--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/UQPQW4J2RIZA7RS7SQNXGRPOFJ4NF6MW/


[Freeipa-users] Re: FreeIPA 4.6.3 on CentOS 7.5?

2018-05-30 Thread Lachlan Musicman via FreeIPA-users
On 30 May 2018 at 23:58, Alexander Bokovoy via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On ke, 30 touko 2018, Zak Wolfinger via FreeIPA-users wrote:
>
>> Is it possible to run FreeIPA 4.6.3 on CentOS 7.5 (build 1804)?
>>
>> It appears to me that 4.6.3 is only available in the Fedora COPR repo.
>> Can anyone direct me to instructions on getting it going on CentOS
>> 7.5.1804?
>>
>
FreeIPA 4.5 works very well on CentOS 7.5 - is there a bug or feature in
particular that you need?

Cheers
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/O2OSEIDM5PSHF6CHJCSGHHU2GT4JSODO/


[Freeipa-users] Re: ipa-client-install - sssd.conf

2018-05-17 Thread Lachlan Musicman via FreeIPA-users
On Wed, May 16, 2018 at 12:04 PM, Ronald Wimmer via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi,
>>
>> is there a way to configure parameters in sssd.conf when calling
>> ipa-client-install? It would be very helpful to be able to specify these
>> parameters:
>>
>> [sssd]
>> default_domain_suffix = SOMEDOMAIN
>>
>> [nss]
>> homedir_substring = /home
>> default_shell = /bin/bash
>>
>> default_shell is the most important one as AD users have /bin/sh as their
>> default shell.
>>
>
It's an interesting question. I've often thought the same thing. In
particular, I wanted to set debug_level and "full_name_format = %1$s", but
since discovering the ansible playbook I've moved towards setting these
thing programmatically. I'd recommend the playbook - you can set your own
default sssd.conf template

https://github.com/freeipa/ansible-freeipa

cheers
L.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/KPQ4ATJYH5TA2FMTWEYAPHQ3QEFA3GTQ/


[Freeipa-users] Re: Problem on dirsrv when updating from 4.5.0 (RHEL 7.4) to 4.5.4 (RHEL 7.5)

2018-05-10 Thread Lachlan Musicman via FreeIPA-users
On 1 May 2018 at 17:40, SOLER SANGUESA Miguel via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> hello,
>
>
>
> I have an IPA master that updated from 4.5.0 (RHEL 7.4) to 4.5.4 (RHEL
> 7.5). An hour later I tried to do the same with the unique replica I have,
> but after update dirsrv is not starting.
>
> It says it is needed run "ipa-server-upgrade", but it also fails:
>
> *# ipactl start*
>
> *Upgrade required: please run ipa-server-upgrade command*
>
> *Aborting ipactl*
>
>
>
> *# ipa-server-upgrade*
>
> *Upgrading IPA:. Estimated time: 1 minute 30 seconds*
>
> *  [1/8]: saving configuration*
>
> *  [2/8]: disabling listeners*
>
> *  [3/8]: enabling DS global lock*
>
> *  [4/8]: starting directory server*
>
> *  [error] CalledProcessError: Command '/bin/systemctl start
> dirsrv@IPA-EXAMOLE-ORG.service' returned non-zero exit status 1*
>
> *  [cleanup]: stopping directory server*
>
> *  [cleanup]: restoring configuration*
>
> *IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
> command ipa-server-upgrade manually.*
>
> *Unexpected error - see /var/log/ipaupgrade.log for details:*
>
> *CalledProcessError: Command '/bin/systemctl start
> dirsrv@IPA-EXAMPLE-ORG.service' returned non-zero exit status 1*
>
> *The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
> more information*
>
>
>
> On the log I can see:
>
> 2018-04-30T14:36:15Z DEBUG Starting external process
>
> 2018-04-30T14:36:15Z DEBUG args=/bin/systemctl is-active
> dirsrv@IPA-EXAMPLE-ORG.service
>
> 2018-04-30T14:36:15Z DEBUG Process finished, return code=3
>
> 2018-04-30T14:36:15Z DEBUG stdout=failed
>
> ...
>
> 2018-04-30T14:36:15Z DEBUG   [4/8]: starting directory server
>
> 2018-04-30T14:36:15Z DEBUG Starting external process
>
> 2018-04-30T14:36:15Z DEBUG args=/bin/systemctl start
> dirsrv@IPA-EXAMPLE-ORG.service
>
> 2018-04-30T14:36:15Z DEBUG Process finished, return code=1
>
> 2018-04-30T14:36:15Z DEBUG stdout=
>
> 2018-04-30T14:36:15Z DEBUG stderr=Job for dirsrv@IPA-EXAMPLE-ORG.service
> failed because the control process exited with error code. See "systemctl
> status dirsrv@IPA-EXAMPLE-ORG.service" and "journalctl -xe" for details.
>
>
>
> 2018-04-30T14:36:15Z DEBUG Traceback (most recent call last):
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 504, in start_creation
>
> run_step(full_msg, method)
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 494, in run_step
>
> method()
>
>   File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
> line 95, in __start
>
> srv.start(self.serverid, ldapi=True)
>
>   File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
> line 161, in start
>
> instance_name, capture_output=capture_output, wait=wait)
>
>   File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
> line 294, in start
>
> skip_output=not capture_output)
>
>   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 542,
> in run
>
> raise CalledProcessError(p.returncode, arg_string, str(output))
>
> CalledProcessError: Command '/bin/systemctl start
> dirsrv@IPA-EXAMPLE-ORG.service' returned non-zero exit status 1
>
>
>
> 2018-04-30T14:36:15Z DEBUG   [error] CalledProcessError: Command
> '/bin/systemctl start dirsrv@IPA-EXAMPLE-ORG.service' returned non-zero
> exit status 1
>
>
>
> Checking /var/log/dirsrv/slapd-IPA-EXAMPLE-ORG/errors I show:
>
> [30/Apr/2018:16:04:52.584220922 +0200] - ERR - slapd_bootstrap_config -
> The default password storage scheme could not be read or was not found in
> the file /etc/dirsrv/slapd-IPA-EXAMPLE-ORG/dse.ldif. It is mandatory.
>
>
>
> Checking on internet I show that "dse.ldif" could be corrupted, so I
> changed with "dse.ldif.startOK" without any change and then I changed with
> "dse.ldif.bak". The problem persist but the error has changed:
>
> [30/Apr/2018:16:32:13.435210918 +0200] - NOTICE - config_set_port -
> Non-Secure Port Disabled
>
> [30/Apr/2018:16:32:13.556581301 +0200] - ERR - symload_report_error -
> Netscape Portable Runtime error -5975: 
> /usr/lib64/dirsrv/plugins/libreplication-plugin.so:
> undefined symbol: replication_legacy_plugin_init
>
> [30/Apr/2018:16:32:13.561590553 +0200] - ERR - symload_report_error -
> Could not load symbol "replication_legacy_plugin_init" from
> "/usr/lib64/dirsrv/plugins/libreplication-plugin.so" for plugin Legacy
> Replication Plugin
>
> [30/Apr/2018:16:32:13.564590264 +0200] - ERR - load_plugin_entry - Unable
> to load plugin "cn=Legacy Replication Plugin,cn=plugins,cn=config"
>
>
>
> I saw a bug about this problem, but it is still opened:
>
> https://bugzilla.redhat.com/show_bug.cgi?format=multiple=1529442
>
>
>
> Any idea how to fix the issue?
>
>
>
> If it is not possible to fix it, can I remove the replica from IPA and
> install it again with the same name?
>


I think I've just bumped into this same problem while updating my dev-ipa

[Freeipa-users] Re: Host is enrolled and installed

2018-05-08 Thread Lachlan Musicman via FreeIPA-users
On 24 April 2018 at 15:43, Lachlan Musicman <data...@gmail.com> wrote:

> On 23 April 2018 at 17:00, Alexander Bokovoy <aboko...@redhat.com> wrote:
>
>> On ma, 23 huhti 2018, Lachlan Musicman via FreeIPA-users wrote:
>>>>
>>>>> Am I making hard work of something that is relatively straight forward
>>>>> and
>>>>> solved elsewhere but I've missed?
>>>>>
>>>>> Ansible has "ignore_errors: True" available, but I feel that is a weak
>>>>> get
>>>>> out of jail free card. Given that this is authentication and
>>>>> authorization,
>>>>> errors shouldn't be ignored (opinion).
>>>>>
>>>> Not really answering your question but did you actually look at
>>>> https://github.com/freeipa/ansible-freeipa instead of creating new
>>>> ones?
>>>
>>>
>>
>> Initial impression: it's a very smooth process using the Ansible scripts.
>> Unfortunately I can reproducibly not login when using it. If
>> ipa-client-install manually I can login.
>>
>> I will have to work through the install-client playbook line by line -
>> there's a lot in the playbook I don't recognise as part of the process.
>> Also, I'm on CentOS which isn't officially supported.
>>
>> But it does install ipa-client very easily.
>>
>
> I should clarify. The client seems to install successfully. From the
> client I can `id user@domain` and get the results I'm looking for. But
> actual login fails. I tried debug_level = 7 and debug_level = 9 but there
> were no errors thrown or obvious failures?
>


For those that come looking after me, I found the problem. For reasons that
I lack the skills to dive into properly, the ansible playbook for
install-client sets two vars in /etc/krb5.conf to false which are set to
true when I run ipa-client-install manually.

By over-riding these two vars to true in the playbook

dns_lookup_realm: true
dns_lookup_kdc: true

I could get it to work as expected.

Cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Host is enrolled and installed

2018-04-23 Thread Lachlan Musicman via FreeIPA-users
 On 23 April 2018 at 17:53, Lachlan Musicman <data...@gmail.com> wrote:

> On 23 April 2018 at 17:00, Alexander Bokovoy <aboko...@redhat.com> wrote:
>
>> On ma, 23 huhti 2018, Lachlan Musicman via FreeIPA-users wrote:
>>
>>> Am I making hard work of something that is relatively straight forward
>>> and
>>> solved elsewhere but I've missed?
>>>
>>> Ansible has "ignore_errors: True" available, but I feel that is a weak
>>> get
>>> out of jail free card. Given that this is authentication and
>>> authorization,
>>> errors shouldn't be ignored (opinion).
>>>
>> Not really answering your question but did you actually look at
>> https://github.com/freeipa/ansible-freeipa instead of creating new ones?
>
>

Initial impression: it's a very smooth process using the Ansible scripts.
Unfortunately I can reproducibly not login when using it. If
ipa-client-install manually I can login.

I will have to work through the install-client playbook line by line -
there's a lot in the playbook I don't recognise as part of the process.
Also, I'm on CentOS which isn't officially supported.

But it does install ipa-client very easily.

cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Host is enrolled and installed

2018-04-23 Thread Lachlan Musicman via FreeIPA-users
On 23 April 2018 at 17:00, Alexander Bokovoy <aboko...@redhat.com> wrote:

> On ma, 23 huhti 2018, Lachlan Musicman via FreeIPA-users wrote:
>
>> Am I making hard work of something that is relatively straight forward and
>> solved elsewhere but I've missed?
>>
>> Ansible has "ignore_errors: True" available, but I feel that is a weak get
>> out of jail free card. Given that this is authentication and
>> authorization,
>> errors shouldn't be ignored (opinion).
>>
> Not really answering your question but did you actually look at
> https://github.com/freeipa/ansible-freeipa instead of creating new ones?



To my shame - not only did I not, I've even got that tab open. Closing
tabs. I should be closing tabs. Thanks Alexander.

Cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Host is enrolled and installed

2018-04-23 Thread Lachlan Musicman via FreeIPA-users
Not 100% sure where to send this. Am trying to write an Ansible playbook to
install SSSD and enroll the host in a domain.

The problem starts when the host exists in the domain and ipa-client is
already installed.

We can use Ansible's delegate module to remove host from domain enrollment
(would be more ideal to test if it's enrolled, then unenroll if test
returns true). And we can use ipa-client-install --uninstall to if
ipa-client is already configured. But neither of these commands provide
easy answers quickly.

ipa host-find {{ host }} | grep matched | cut -d " " -f 1

will turn ipa host-find into something usable. A switch that just returned
the number matched would be ideal, but it's workable currently.


More interestingly, once a host is unenrolled from the domain (ie, ipa
host-del  runs successfully on the IPA server), it doesn't, and
probably shouldn't, uninstall ipa-client on the host itself.

But there doesn't seem to be any way to check ipa-client
--install/--uninstall for it's opposite.

IE, if ipa-client is installed, and is run again, one is urged to uninstall
first:

IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using
'ipa-client-install --uninstall'.
The ipa-client-install command failed. See /var/log/ipaclient-install.log
for more information

if ipa-client is not installed, and you run

ipa-client --uninstall

The message returned is:

IPA client is not configured on this system.
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log
for more information

Have I missed a true/false return value cli arg for ipa-client-install?

ipa-client-install --exists
ipa-client-install --configured

or something like that?



Am I making hard work of something that is relatively straight forward and
solved elsewhere but I've missed?

Ansible has "ignore_errors: True" available, but I feel that is a weak get
out of jail free card. Given that this is authentication and authorization,
errors shouldn't be ignored (opinion).

cheers
L.


--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] FreeIPA Ansible scripts

2018-03-28 Thread Lachlan Musicman via FreeIPA-users
Has anyone on the list used the FreeIPA Ansible scripts?

https://github.com/freeipa/ansible-freeipa

It looks relatively up to date and functional.

Cheers
L.

--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Announcing SSSD 1.16.1

2018-03-28 Thread Lachlan Musicman via FreeIPA-users
On 29 March 2018 at 06:45, Jakub Hrozek  wrote:

> > On 28 Mar 2018, at 21:20, Rob Crittenden  wrote:
> >
> > What COPR is that?
>
> The SSSD team copr:
> https://copr.fedorainfracloud.org/groups/g/sssd/coprs/
>
> Fabiano already built the packages, I just forgot to reply to this e-mail:
> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/
>
> (we are working on making the builds automatically available when a new
> release is tagged, so far the process is manual and that’s why we forgot..)
>

Thankyou Rob, Jacob and Fabiano
cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Announcing SSSD 1.16.1

2018-03-27 Thread Lachlan Musicman via FreeIPA-users
 On 9 March 2018 at 23:28, Jakub Hrozek via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> SSSD 1.16.1
> ===
>
> The SSSD team is proud to announce the release of version 1.16.1 of the
> System Security Services Daemon.
>
> The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/
>
> RPM packages will be made available for Fedora shortly.
>
> Feedback
> 
> Please provide comments, bugs and other feedback
> via the sssd-devel or sssd-users mailing lists:
>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>


I was going to wait patiently for this to flow through the regular channels
but between GoScanSSH and some of the fixes available (2FA password
changes, speed improvements), I'm going to ask:

Can this release get pushed to COPR please?

Cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Maintenance mode

2017-12-06 Thread Lachlan Musicman via FreeIPA-users
Stupid question, but to stop anyone from logging in anywhere - for instance
during a maintenance period - is there an easy maintenance mode in IPA?

Or is the best method to disable all HBAC rules?

cheers
L.
--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Upgrade from CentOS 7.3 to 7.4 - Safe?

2017-11-11 Thread Lachlan Musicman via FreeIPA-users
Yep! Just yum upgrade -y

cheers
L.

--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857

On 11 November 2017 at 04:08, Christophe TREFOIS <christophe.tref...@uni.lu>
wrote:

> Hi,
>
> How did you proceed? One by one just a yum update on all pending packages?
>
> --
>
> Dr Christophe Trefois, Dipl.-Ing.
> Technical Specialist / Post-Doc
>
> UNIVERSITÉ DU LUXEMBOURG
>
> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
> Campus Belval | House of Biomedicine
> 6, avenue du Swing
> L-4367 Belvaux
> T: +352 46 66 44 6124 <+352%2046%2066%2044%206124>
> F: +352 46 66 44 6949 <+352%2046%2066%2044%206949>
> http://www.uni.lu/lcsb
>
> [image: Facebook] <https://www.facebook.com/trefex>  [image: Twitter]
> <https://twitter.com/Trefex>  [image: Google Plus]
> <https://plus.google.com/+ChristopheTrefois/>  [image: Linkedin]
> <https://www.linkedin.com/in/trefoischristophe>  [image: skype]
> <http://skype:Trefex?call>
>
> 
> This message is confidential and may contain privileged information.
> It is intended for the named recipient only.
> If you receive it in error please notify me and permanently delete the
> original message and any copies.
> 
>
>
> On 10 Nov 2017, at 00:30, Lachlan Musicman via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> On 10 November 2017 at 10:17, Christophe TREFOIS via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hi,
>>
>>
>>
>> Is it considered safe to go from CentOS 7.3 FreeIPA 4.4 to CentOS 7.4
>> with FreeIPA 4.5?
>>
>>
>>
>> Anything that we should know? Any issues? Things to consider?
>>
>>
>>
>> Should we run yum update on all pending packages replica by replica?
>>
>>
>>
>> Thanks for any feedback or stories you might have encountered.
>>
>
>
> We upgraded our test env and tested it and that worked as we expected. So
> we then did the same to our production env, and that also worked as
> expected. Which was really nice :)
>
>
> cheers
> L.
>
> --
> "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
> civics is the insistence that we cannot ignore the truth, nor should we
> panic about it. It is a shared consciousness that our institutions have
> failed and our ecosystem is collapsing, yet we are still here — and we are
> creative agents who can shape our destinies. Apocalyptic civics is the
> conviction that the only way out is through, and the only way through is
> together. "
>
> *Greg Bloom* @greggish https://twitter.com/greggish/status/
> 873177525903609857
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] master - replica relationship

2017-11-07 Thread Lachlan Musicman via FreeIPA-users
Hola,

I'm still trying to wrap my head around the master-replica concept.

>From what I read in the documentation (Chapter 4 of
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/
)

the replica should be able to take over as master should master go offline.

Our replica was set up with CA & without DNS - the same as master, and it
seems to be working on the whole.

The problem I'm having is in the replication.
create user on master:

ipa user-add master_test_user --first=MT --last=ML

create user on replica:

ipa user-add replica_test_user --first=RT --last=RL

find user on master:

[root@vmpr-linuxidm ~]# ipa user-find test_user
---
2 users matched
---
  User login: master_test_user
  First name: MT
  Last name: ML
  Home directory: /home/master_test_user
  Login shell: /bin/bash
  Principal name: master_test_u...@unix.domain.com
  Principal alias: master_test_u...@unix.domain.com
  Email address: master_test_u...@domain.com
  UID: 1718800021
  GID: 1718800021
  Account disabled: False

  User login: replica_test_user
  First name: RT
  Last name: RL
  Home directory: /home/replica_test_user
  Login shell: /bin/bash
  Principal name: replica_test_u...@unix.domain.com
  Principal alias: replica_test_u...@unix.domain.com
  Email address: replica_test_u...@domain.com
  UID: 1718850502
  GID: 1718850502
  Account disabled: False

Number of entries returned 2


find user on replica:
[root@vmdr-linuxidm ~]# ipa user-find test_user
--
1 user matched
--
  User login: replica_test_user
  First name: RT
  Last name: RL
  Home directory: /home/replica_test_user
  Login shell: /bin/bash
  Principal name: replica_test_u...@unix.domain.com
  Principal alias: replica_test_u...@unix.domain.com
  Email address: replica_test_u...@domain.com
  UID: 1718850502
  GID: 1718850502
  Account disabled: False

Number of entries returned 1


If I run ipa user-add on the replica, I see it upstream on master, but if I
run ipa add-user on the master, that's not replicated down to the replica.

Also, ipa user-del (even with --no-preserve) works on master, but doesn't
delete the user on the replica.

What has gone wrong?

Cheers
L.



--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: libsemanage updates fail due to AD user with space

2017-10-31 Thread Lachlan Musicman via FreeIPA-users
On 4 April 2017 at 17:44, Lukas Slebodnik  wrote:

> >>> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
> >>> >
> >>> > With SSSD/IPA in use, in a one way trust to AD, and AD users have
> spaces
> >>> in
> >>> > their names, libsemanage fails to update:
> >>> >
> >>> > eg from recent monthly upgrade cycle:
> >>> >
> >>> > Updating   :
> >>> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
> >>> > 3/14
> >>> > libsemanage.parse_assert_ch: expected character ':', but found 'f'
> >>> > (/etc/selinux/targeted/tmp/seusers.local: 5):
> >>> > lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such
> file
> >>> or
> >>> > directory).
> >>> > libsemanage.seuser_parse: could not parse seuser record (No such
> file or
> >>> > directory).
> >>> > libsemanage.dbase_file_cache: could not cache file database (No such
> file
> >>> > or directory).
> >>> > libsemanage.semanage_base_merge_components: could not merge local
> >>> > modifications into policy (No such file or directory).
> >>> >
> >>>
> >>> Hi,
> >>> according to my quick testing this is solved with this PR:
> >>> https://github.com/SSSD/sssd/pull/189
> >This patch will not help with spaces in name.
> >
> >it need to be fixed in selinux-policy or libsemanage.
> >
>
> It looks like it happen with each upgrade of selinux-policy.
> I assume it might be some missing quoting in rpm bash scriptlet.
>
> It should not be difficult to reproduce and file a bug.
> Feel free to add to CC my mail.
>



Lukas,

I've just seen this again. When you said "file a bug" did you mean against
ipa or against selinux?

(I've just seen it again)



Updating   :
selinux-policy-targeted-3.13.1-166.el7_4.5.noarch
56/149
libsemanage.parse_assert_ch: expected character ':', but found 'j'
(/etc/selinux/targeted/tmp/seusers.local: 5):
last ja...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or
directory).
libsemanage.seuser_parse: could not parse seuser record (No such file or
directory).
libsemanage.dbase_file_cache: could not cache file database (No such file
or directory).
libsemanage.semanage_base_merge_components: could not merge local
modifications into policy (No such file or directory).
/usr/sbin/semodule:  Failed!


cheers
L.



--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replica stopped working: pki-ca port failed?

2017-10-26 Thread Lachlan Musicman via FreeIPA-users
On 27 October 2017 at 07:38, Rob Crittenden <rcrit...@redhat.com> wrote:

> Lachlan Musicman via FreeIPA-users wrote:
>
> >
> > ipa -version
> > VERSION: 4.5.0, API_VERSION: 2.228
>
> It shouldn't be even trying port 7389 with v4.5.0. Very old versions of
> IPA used to use two separate 389-ds instances, one for the IPA data and
> one for the CA data. They were combined long ago. This could just be a
> check in case you had a very old master in which case this is a red
> herring.
>
>

I went back to take another look at the dirsrv logs after you said this,
and I saw something I didn't see yesterday. I notice that the cn has "meTo"
appended to the start of the master server name.

Is that meant to be that way, or have I mistyped in the wrong window at the
wrong time somewhere?

ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=
meTovmpr-linuxidm.unix.domain.com" (vmpr-linuxidm:389) - Replication bind
with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()


Cheers
L.


--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replica stopped working: pki-ca port failed?

2017-10-26 Thread Lachlan Musicman via FreeIPA-users
On 27 October 2017 at 10:32, Lachlan Musicman <data...@gmail.com> wrote:

> On 27 October 2017 at 07:38, Rob Crittenden <rcrit...@redhat.com> wrote:
>
>> Lachlan Musicman via FreeIPA-users wrote:
>> >
>> > When I look at the ID Views in the interface, I get an "IPA Error 903:
>> > InternalError".
>>
>> See /var/log/httpd/error_log for details, there may be a python backtrace.
>>
>
> Sure do!
>
> [Thu Oct 26 12:57:25.413102 2017] [:error] [pid 1316] ipa: ERROR:
> non-public: RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
> [Thu Oct 26 12:57:25.413118 2017] [:error] [pid 1316] Traceback (most
> recent call last):
> [Thu Oct 26 12:57:25.413121 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 367, in
> wsgi_execute
> [Thu Oct 26 12:57:25.413124 2017] [:error] [pid 1316] result =
> command(*args, **options)
> [Thu Oct 26 12:57:25.413126 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in
> __call__
> [Thu Oct 26 12:57:25.413128 2017] [:error] [pid 1316] return
> self.__do_call(*args, **options)
> [Thu Oct 26 12:57:25.413130 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in
> __do_call
> [Thu Oct 26 12:57:25.413133 2017] [:error] [pid 1316] ret =
> self.run(*args, **options)
> [Thu Oct 26 12:57:25.413135 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run
> [Thu Oct 26 12:57:25.413137 2017] [:error] [pid 1316] return
> self.execute(*args, **options)
> [Thu Oct 26 12:57:25.413139 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line
> 2050, in execute
> [Thu Oct 26 12:57:25.413141 2017] [:error] [pid 1316] truncated =
> callback(self, ldap, entries, truncated, *args, **options)
> [Thu Oct 26 12:57:25.413144 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 1123, in post_callback
> [Thu Oct 26 12:57:25.413146 2017] [:error] [pid 1316] ldap, entries,
> truncated, *args, **options)
> [Thu Oct 26 12:57:25.413148 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 829, in post_callback
> [Thu Oct 26 12:57:25.413151 2017] [:error] [pid 1316]
> self.obj.convert_anchor_to_human_readable_form(entry, **options)
> [Thu Oct 26 12:57:25.413153 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 733, in convert_anchor_to_human_readable_form
> [Thu Oct 26 12:57:25.413156 2017] [:error] [pid 1316] anchor
> [Thu Oct 26 12:57:25.413158 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 632, in resolve_anchor_to_object_name
> [Thu Oct 26 12:57:25.413161 2017] [:error] [pid 1316] name =
> domain_validator.get_trusted_domain_object_from_sid(sid)
> [Thu Oct 26 12:57:25.413163 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 503, in
> get_trusted_domain_object_from_sid
> [Thu Oct 26 12:57:25.413165 2017] [:error] [pid 1316] attrs=attrs)
> [Thu Oct 26 12:57:25.413167 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 380, in
> get_trusted_domain_objects
> [Thu Oct 26 12:57:25.413170 2017] [:error] [pid 1316] entries =
> self.search_in_dc(domain, filter, attrs, scope, basedn)
> [Thu Oct 26 12:57:25.413172 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 689, in
> search_in_dc
> [Thu Oct 26 12:57:25.413174 2017] [:error] [pid 1316] info =
> self.__retrieve_trusted_domain_gc_list(domain)
> [Thu Oct 26 12:57:25.413176 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 763, in
> __retrieve_trusted_domain_gc_list
> [Thu Oct 26 12:57:25.413179 2017] [:error] [pid 1316]
> os.path.join(paths.USR_SHARE_IPA_DIR, "smb.conf.empty"))
> [Thu Oct 26 12:57:25.413181 2017] [:error] [pid 1316] RuntimeError: Unable
> to load file /usr/share/ipa/smb.conf.empty
>
>
> >
>> > [26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could
>> > not get initial credentials for principal
>> > [ldap/vmdr-linuxidm.unix.domain@unix.domain.com
>> > <mailto:vmdr-linuxidm.unix.domain@unix.domain.com>] in keytab
>> > [FILE:/etc/dirsrv/ds.

[Freeipa-users] Replica stopped working: pki-ca port failed?

2017-10-25 Thread Lachlan Musicman via FreeIPA-users
When I first installed our replica, it worked just fine - I could add a
user and see it on the master server. And vice versa.

I recently went back to take a look and make sure everything was working -
and it's not.

ipactl status shows everything is ok. Munge is up. I can ssh hostname
between machines.

When I look at the ID Views in the interface, I get an "IPA Error 903:
InternalError".

When I do an id  I get nosuch user.

I did some googling. In /var log/dirsrv/domain/errors I found this:

[26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
vmdr-linuxidm.unix.domain@unix.domain.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)

I can get `kinit admin` working fine. But there's something wrong. I don't
know where to look exactly.

/var/log/httpd/error has this

RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty

Which is interesting. There's no file /usr/share/ipa/smb.conf.empty but
there is a /usr/share/ipa/smb.conf.template?


Ok, I think I've found the problem:

ipa-replica-conncheck -c -m 
Failed to connect to port 7389 tcp on 10.126.18.73
   PKI-CA: Directory Service port (7389): FAILED
ERROR: Port check failed! Inaccessible port(s): 7389 (TCP)


On the master, pki-tomcatd is showing as OK, although nmap -sT -O localhost
doesn't show 7389 open.

Where can I look next?

ipa -version
VERSION: 4.5.0, API_VERSION: 2.228

cheers
L.

--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

2017-09-20 Thread Lachlan Musicman via FreeIPA-users
On 20 September 2017 at 16:15, Lachlan Musicman  wrote:

> On 20 September 2017 at 15:54, Alexander Bokovoy 
> wrote:
>
>>
>> Ok. By the look of this commit (to 4.5):
>>>
>>> https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
>>>
>>> from this issue https://pagure.io/freeipa/issue/7083
>>>
>>> It is (or was)  the IPv6 problem.
>>>
>>> We have an
>>>
>>> [root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
>>> # Disable IPv6
>>> net.ipv6.conf.all.disable_ipv6 = 1
>>> net.ipv6.conf.ens160.disable_ipv6 = 1
>>>
>>> We don't have the 'lo' interface defined in there, but it's never been an
>>> issue.
>>>
>>> The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.
>>>
>> I'm a bit tired to repeat this multiple times but FreeIPA does require
>> IPv6 stack to be enabled in the kernel. We absolutely do. If you don't
>> use IPv6 stack, disable it on specific interfaces. However, there is a
>> practical problem with the way how glibc DNS resolver works: in default
>> configuration it always prefers IPv6 answers to IPv4 because this is
>> actually a policy of RFC3484. As result, if you have ::1 in /etc/hosts,
>> it will be returned first. If you don't have ::1 on any of your
>> interfaces ('lo' is a typical one), then apps cannot contact ::1
>> (localhost) even if those apps that use IPv6 bind to all interfaces.
>>
>> FreeIPA uses modern APIs provided by glibc to listen on both IPv6 and
>> IPv4. It simply means that FreeIPA servers bind to IPv6 addresses (on
>> all interfaces or on a specific one, if needed) and treat IPv4 as mapped
>> ones because IPv6 and IPv4 share the same port space on the same
>> machine. This works transparently thanks to glibc and is a recommended
>> way to write networking applications. See man ipv6(7) for details.
>>
>> Here is how it looks on a real system, for TCP listeners:
>>
>> # netstat -nltp
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address   Foreign Address
>>  State   PID/Program nametcp0  0 127.0.0.1:953
>>  0.0.0.0:*   LISTEN  13361/named-pkcs11  tcp
>> 0  0 0.0.0.0:445 0.0.0.0:*   LISTEN
>> 13760/smbd  tcp0  0 0.0.0.0:49152   0.0.0.0:*
>>  LISTEN  13765/smbd  tcp0  0
>> 0.0.0.0:135 0.0.0.0:*   LISTEN  13763/smbd
>> tcp0  0 0.0.0.0:139 0.0.0.0:*
>>LISTEN  13760/smbd  tcp0  0 0.0.0.0:749
>>0.0.0.0:*   LISTEN  13351/kadmind   tcp
>>   0  0 0.0.0.0:464 0.0.0.0:*   LISTEN
>> 13351/kadmind   tcp0  0 192.168.100.233:53  0.0.0.0:*
>>  LISTEN  13361/named-pkcs11  tcp0  0
>> 127.0.0.1:530.0.0.0:*   LISTEN
>> 13361/named-pkcs11  tcp0  0 0.0.0.0:22  0.0.0.0:*
>>  LISTEN  2838/sshd   tcp0  0
>> 0.0.0.0:88  0.0.0.0:*   LISTEN
>> 13345/krb5kdc   tcp6   0  0 ::1:953 :::*
>> LISTEN  13361/named-pkcs11  tcp6   0  0 :::8443
>>  :::*LISTEN  13603/java  tcp6
>>  0  0 :::443  :::*LISTEN
>> 13379/httpd tcp6   0  0 :::636  :::*
>> LISTEN  13296/ns-slapd  tcp6   0  0 :::445
>> :::*LISTEN  13760/smbd  tcp6
>>0  0 :::49152:::*LISTEN
>> 13765/smbd  tcp6   0  0 :::9090 :::*
>> LISTEN  1/systemd   tcp6   0  0
>> 127.0.0.1:8005  :::*LISTEN  13603/java
>> tcp6   0  0 :::389  :::*
>> LISTEN  13296/ns-slapd  tcp6   0  0 :::135
>> :::*LISTEN  13763/smbd  tcp6   0  0
>> 127.0.0.1:8009  :::*LISTEN  13603/java
>> tcp6   0  0 :::139  :::*
>> LISTEN  13760/smbd  tcp6   0  0 :::749
>> :::*LISTEN  13351/kadmind   tcp6   0  0
>> :::8080 :::*LISTEN  13603/java
>> tcp6   0  0 :::80   :::*
>> LISTEN  13379/httpd tcp6   0  0 :::464
>> :::*LISTEN  13351/kadmind   tcp6   0  0
>> :::53   :::*LISTEN
>> 13361/named-pkcs11  tcp6   0  0 :::22   :::*
>> LISTEN  2838/sshd   tcp6   0  0 :::88
>>  :::*LISTEN  13345/krb5kdc
>> Notice that many ports are only available as tcp6 

[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

2017-09-20 Thread Lachlan Musicman via FreeIPA-users
On 20 September 2017 at 15:54, Alexander Bokovoy 
wrote:

>
> Ok. By the look of this commit (to 4.5):
>>
>> https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
>>
>> from this issue https://pagure.io/freeipa/issue/7083
>>
>> It is (or was)  the IPv6 problem.
>>
>> We have an
>>
>> [root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
>> # Disable IPv6
>> net.ipv6.conf.all.disable_ipv6 = 1
>> net.ipv6.conf.ens160.disable_ipv6 = 1
>>
>> We don't have the 'lo' interface defined in there, but it's never been an
>> issue.
>>
>> The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.
>>
> I'm a bit tired to repeat this multiple times but FreeIPA does require
> IPv6 stack to be enabled in the kernel. We absolutely do. If you don't
> use IPv6 stack, disable it on specific interfaces. However, there is a
> practical problem with the way how glibc DNS resolver works: in default
> configuration it always prefers IPv6 answers to IPv4 because this is
> actually a policy of RFC3484. As result, if you have ::1 in /etc/hosts,
> it will be returned first. If you don't have ::1 on any of your
> interfaces ('lo' is a typical one), then apps cannot contact ::1
> (localhost) even if those apps that use IPv6 bind to all interfaces.
>
> FreeIPA uses modern APIs provided by glibc to listen on both IPv6 and
> IPv4. It simply means that FreeIPA servers bind to IPv6 addresses (on
> all interfaces or on a specific one, if needed) and treat IPv4 as mapped
> ones because IPv6 and IPv4 share the same port space on the same
> machine. This works transparently thanks to glibc and is a recommended
> way to write networking applications. See man ipv6(7) for details.
>
> Here is how it looks on a real system, for TCP listeners:
>
> # netstat -nltp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State
>  PID/Program nametcp0  0 127.0.0.1:953
>  0.0.0.0:*   LISTEN  13361/named-pkcs11  tcp0
>   0 0.0.0.0:445 0.0.0.0:*   LISTEN
> 13760/smbd  tcp0  0 0.0.0.0:49152   0.0.0.0:*
>  LISTEN  13765/smbd  tcp0  0
> 0.0.0.0:135 0.0.0.0:*   LISTEN  13763/smbd
>   tcp0  0 0.0.0.0:139 0.0.0.0:*
>  LISTEN  13760/smbd  tcp0  0 0.0.0.0:749
>0.0.0.0:*   LISTEN  13351/kadmind   tcp0
> 0 0.0.0.0:464 0.0.0.0:*   LISTEN
> 13351/kadmind   tcp0  0 192.168.100.233:53  0.0.0.0:*
>  LISTEN  13361/named-pkcs11  tcp0  0
> 127.0.0.1:530.0.0.0:*   LISTEN
> 13361/named-pkcs11  tcp0  0 0.0.0.0:22  0.0.0.0:*
>  LISTEN  2838/sshd   tcp0  0
> 0.0.0.0:88  0.0.0.0:*   LISTEN
> 13345/krb5kdc   tcp6   0  0 ::1:953 :::*
> LISTEN  13361/named-pkcs11  tcp6   0  0 :::8443
>  :::*LISTEN  13603/java  tcp6
>  0  0 :::443  :::*LISTEN
> 13379/httpd tcp6   0  0 :::636  :::*
> LISTEN  13296/ns-slapd  tcp6   0  0 :::445
> :::*LISTEN  13760/smbd  tcp6
>0  0 :::49152:::*LISTEN
> 13765/smbd  tcp6   0  0 :::9090 :::*
> LISTEN  1/systemd   tcp6   0  0
> 127.0.0.1:8005  :::*LISTEN  13603/java
>   tcp6   0  0 :::389  :::*
> LISTEN  13296/ns-slapd  tcp6   0  0 :::135
> :::*LISTEN  13763/smbd  tcp6   0  0
> 127.0.0.1:8009  :::*LISTEN  13603/java
>   tcp6   0  0 :::139  :::*
> LISTEN  13760/smbd  tcp6   0  0 :::749
> :::*LISTEN  13351/kadmind   tcp6   0  0
> :::8080 :::*LISTEN  13603/java
> tcp6   0  0 :::80   :::*
> LISTEN  13379/httpd tcp6   0  0 :::464
> :::*LISTEN  13351/kadmind   tcp6   0  0
> :::53   :::*LISTEN
> 13361/named-pkcs11  tcp6   0  0 :::22   :::*
> LISTEN  2838/sshd   tcp6   0  0 :::88
>  :::*LISTEN  13345/krb5kdc
> Notice that many ports are only available as tcp6 listeners? Like 636
> (LDAPS), 389 (LDAP), 80 (HTTP), 443 (HTTPS) and so on? This is an effect
> of using v6 API that supports v4-mapped-on-v6 addresses. It makes the
> code less 

[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

2017-09-19 Thread Lachlan Musicman via FreeIPA-users
On 20 September 2017 at 13:01, Lachlan Musicman  wrote:

> https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
> On 20 September 2017 at 12:30, Fraser Tweedale 
> wrote:
>
>>
>> Can you please provide log files?  Especially
>> /var/log/ipaupgrade.log, to begin with.
>>
>
> Fraser, thanks for the reply. I meant to answer my own email with the
> solution but I couldn't see it on the list?
>
> Anyway - the solution was that the /etc/hosts file on the server in
> question had a ::1 localhost address. We have the IPv6 disabled
> (combination of one of our services not working with IPv6 and our network
> not being IPv6 ready) in the OS.
>
> Once I deleted that line from /etc/hosts, everything went to plan.
>
>
Ok. By the look of this commit (to 4.5):

https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858

from this issue https://pagure.io/freeipa/issue/7083

It is (or was)  the IPv6 problem.

We have an

[root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.ens160.disable_ipv6 = 1

We don't have the 'lo' interface defined in there, but it's never been an
issue.

The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.

cheers
L.


--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

2017-09-19 Thread Lachlan Musicman via FreeIPA-users
On 20 September 2017 at 12:30, Fraser Tweedale <ftwee...@redhat.com> wrote:

> On Wed, Sep 20, 2017 at 08:50:03AM +1000, Lachlan Musicman via
> FreeIPA-users wrote:
> > 2017-09-19T22:30:50Z DEBUG wait_for_open_ports: localhost [8080, 8443]
> > timeout 300
> > 2017-09-19T22:35:51Z ERROR IPA server upgrade failed: Inspect
> > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
> > 2017-09-19T22:35:51Z DEBUG   File "/usr/lib/python2.7/site-
> > packages/ipapython/admintool.py", line 172, in execute
> > return_value = self.run()
> >   File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_
> server_upgrade.py",
> > line 46, in run
> > server.upgrade()
> >   File "/usr/lib/python2.7/site-packages/ipaserver/install/server/
> upgrade.py",
> > line 1913, in upgrade
> > upgrade_configuration()
> >   File "/usr/lib/python2.7/site-packages/ipaserver/install/server/
> upgrade.py",
> > line 1652, in upgrade_configuration
> > ca.start('pki-tomcat')
> >   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > line 401, in start
> > self.service.start(instance_name, capture_output=capture_output,
> > wait=wait)
> >   File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/service
> s.py",
> > line 211, in start
> > instance_name, capture_output=capture_output, wait=wait)
> >   File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
> > line 300, in start
> > self.wait_for_open_ports(self.service_instance(instance_name))
> >   File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
> > line 270, in wait_for_open_ports
> > self.api.env.startup_timeout)
> >   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
> 1227,
> > in wait_for_open_ports
> > raise socket.timeout("Timeout exceeded")
> >
> > 2017-09-19T22:35:51Z DEBUG The ipa-server-upgrade command failed,
> > exception: timeout: Timeout exceeded
> > 2017-09-19T22:35:51Z ERROR Timeout exceeded
> > 2017-09-19T22:35:51Z ERROR The ipa-server-upgrade command failed. See
> > /var/log/ipaupgrade.log for more information
> >
>


>
> Can you please provide log files?  Especially
> /var/log/ipaupgrade.log, to begin with.
>

Fraser, thanks for the reply. I meant to answer my own email with the
solution but I couldn't see it on the list?

Anyway - the solution was that the /etc/hosts file on the server in
question had a ::1 localhost address. We have the IPv6 disabled
(combination of one of our services not working with IPv6 and our network
not being IPv6 ready) in the OS.

Once I deleted that line from /etc/hosts, everything went to plan.

Note: my analysis was not my own, it on this came from this site:

https://awsadminz.com/ipa-wait_for_open_ports-localhost-8080-8443-timeout-300/

Their solution worked, so I ran with it.


cheers
L.

--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish https://twitter.com/greggish/
status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] 7.4 upgrade fails with timeout exceeded

2017-09-19 Thread Lachlan Musicman via FreeIPA-users
2017-09-19T22:30:50Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 300
2017-09-19T22:35:51Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-09-19T22:35:51Z DEBUG   File "/usr/lib/python2.7/site-
packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 46, in run
server.upgrade()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1913, in upgrade
upgrade_configuration()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1652, in upgrade_configuration
ca.start('pki-tomcat')
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 401, in start
self.service.start(instance_name, capture_output=capture_output,
wait=wait)
  File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 211, in start
instance_name, capture_output=capture_output, wait=wait)
  File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
line 300, in start
self.wait_for_open_ports(self.service_instance(instance_name))
  File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
line 270, in wait_for_open_ports
self.api.env.startup_timeout)
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1227,
in wait_for_open_ports
raise socket.timeout("Timeout exceeded")

2017-09-19T22:35:51Z DEBUG The ipa-server-upgrade command failed,
exception: timeout: Timeout exceeded
2017-09-19T22:35:51Z ERROR Timeout exceeded
2017-09-19T22:35:51Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information




How do I fix? Is there a patch available?

This process went smoothly in testing, so I rolled out to prod. We need
this up and running.


cheers
L.
--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Centos/Redhat 7.4

2017-08-23 Thread Lachlan Musicman via FreeIPA-users
What version of IPA is available in 7.4?

cheers
L.
--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away

2017-07-12 Thread Lachlan Musicman via FreeIPA-users
On 13 July 2017 at 00:48, bogusmaster--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> > On Thu, Jul 06, 2017 at 02:29:34PM -, bogusmaster--- via
> FreeIPA-users wrote:
>
> I have verified that hint. I've stopped sssd daemon, cleared the cache and
> started it back again. Although ipa commands are returning correct members
> of the group, when in issue getent group ... on the server it still returns
> old members of the group that are not present in the group returned by ipa
> command.
> Can you please advise on how I can troubleshoot it further?
>


There are two parts to IPA - ipa server which does the "server" part, and
SSSD, which does the client part. On the IPA server itself, if you are
using SSSD, you might need to also update SSSD to 1.15.2-5 and clear the
cache?

ipa-client basically installs SSSD and configures it for the ipa server in
question.

cheers
L.


--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrisse Cullors, *Black Lives Matter founder*
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away

2017-07-07 Thread Lachlan Musicman via FreeIPA-users
Thank you for sharing this hint, I am going to try the upgrade. Can I ask
you which version of IPA did you use with that sssd version? Did you
upgrade sssd on each type of server (I mean both client and server)?




I did a test roll out to just the clients before going to all. We are using
the freeIPA that is currently in CentOS/EPEL - 4.4 I think?

Cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrisse Cullors, *Black Lives Matter founder*

On 7 July 2017 at 22:54, bogusmaster--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:




> Many thanks,
> Bart
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away

2017-07-06 Thread Lachlan Musicman via FreeIPA-users
On 7 July 2017 at 00:29, bogusmaster--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Just to add some example of behaviour I described, I configured an AD user
> group membership and granted him access via HBAC rule. Waited approximately
> for 2 hours and then, all of a sudden, it magically works without me
> changing anything :). Below is the log excerpt from /var/log/secure which
> caught the moment when HBAC rule seemingly started working with no action
> on my side:
>


You are describing the symptoms I saw exactly. The newer SSSD version
(1.15.2-5) from the COPR repo (which is managed by some of the sssd
developers) solved my problems.

cheers
L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away

2017-07-05 Thread Lachlan Musicman via FreeIPA-users
Bart,

Which versions of SSSD and FreeIPA are you using?

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrisse Cullors, *Black Lives Matter founder*

On 6 July 2017 at 00:22, bogusmaster--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi all,
>
> I have set up trust between FreeIPA and AD. Users from AD domain can
> successfully log into the linux boxes when I have allow_all rule enabled.
> However, when I try to achieve something more fancy, like assigning set of
> users to a custom group (firstly external, then the posix one) or make it
> possible for AD users to use ssh public key authentication via Default
> Trust View user settings override, FreeIPA behaves in slightly
> nondeterministic way. It manifests itself in a couple of ways:
> - users that I uploaded SSH keys for can't use them right away. Sometimes
> it is a matter of minutes, sometimes it is a matter of hours for the ssh
> public keys to work. I observed that when I add a couple of keys, then
> whenever one ssh public key starts working for one user, it works for all
> of them.
> - the same as above applies to AD users that are added to a group which
> later on is used in HBAC rule definition. When I add a user to this group,
> he/she can't log in straight away but it takes some time to propagate.
> - and last but not least: when I delete a user who can successfully log
> into a Linux box from a group which is used in HBAC rule definition, he/she
> can still log in to that box. To make things more awkward, user can access
> one client machine as if they wasn't deleted from the group whereas they
> can't access other client machine and receives "Connection closed by
> UNKNOWN" response upon ssh connection establishment (which is desired in
> both Linux machines).
>
> I tried to clear sssd cache by issuing sss_cache -E and restarted sssd
> daemon  on Linux machine which is affected by that behaviour, but to no
> avail.
>
> Can someone please point me to what I can do to troubleshoot this further
> and make changes applied to IPA server be visible right away?
>
> Many thanks,
> Bart
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Fwd: Logwatch and FreeIPA/sssd

2017-06-22 Thread Lachlan Musicman via FreeIPA-users
Hola,

I have logwatch set up on my server, and there is a stanza in my daily
email called "**Unmatched Entries**", which is filled with lines from
either ipa or sssd:

Failed password for usen...@domain.com from 10.126.67.170 port 57331 ssh2 :
2 time(s)
Accepted password for usen...@domain.com from 10.126.67.170 port 61402 ssh2
: 1 time(s)
pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh
ruser= rhost=hostname.domain.com user=usen...@domain.com : 1 time(s)


Does anyone have a logwatch .conf script that they have written? Does such
a thing formally exist for ipa/sssd?

cheers
L.


--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrisse Cullors, *Black Lives Matter founder*
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org