Re: [Freeipa-users] need info on AD / IPA coexistence

2012-03-13 Thread Rob Crittenden 

Sylvain Angers wrote:



2012/3/8 Brian Cook mailto:bc...@redhat.com>>

Also, I would not use 'delegation record' from AD, use conditional
forwarding for *.unix.abcd.ca .  Your AD admins
should know how to do it.

---
Brian Cook
Solutions Architect, Red Hat, Inc.
407-212-7079 




On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote:


On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote:

Alright!

I am now requesting to our DNS team

please delegate dns zone "unix.abcd.ca " to ???


the ip address of your ipa server, they will know what questions to
ask :)


Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca
 or
ipaserver.abcd.ca ?



does it matter?


It does, the IPa server DNS domain is what matters for the first
master.
So it should be .unix.abcd.ca 

So that DNS domain = unix.abcd.ca  and realm
= UNIX.ABCD.CA  (if you use
the standard configuration).

Simo.

--
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/mailman/listinfo/freeipa-users



Hello

Still have same issue "unable to find 'admin' user with 'getent passwd
admin'!

I redid both client and servers, no selinux,no firewall

Our dns teams did set soa unix.cnppd.lab to point to my ipa server

I had to put a manual entry in /etc/hosts
165.115.118.21  mtl-ipa01d.unix.cnppd.lab   mtl-ipa01d


then did set my ipa server with the following
*ipa-server-install -a xxx --hostname=mtl-ipa01d.unix.cnppd.lab -n
unix.cnppd.lab -p x -r UNIX.CNPPD.LAB --setup-dns
--forwarder=165.115.52.21--fowarder=165.115.51.21*
Server host name [mtl-ipa01d.unix.cnppd.lab]:

Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab
The IPA Master Server will be configured with
Hostname:mtl-ipa01d.unix.cnppd.lab
IP address:  165.115.118.21
Domain name: unix.cnppd.lab

Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [118.115.165.in-addr.arpa.]:
Using reverse zone 118.115.165.in-addr.arpa.


Restarting the directory server
Restarting the KDC
Restarting the web server
Configuring named:
   [1/9]: adding DNS container
   [2/9]: setting up our zone
   [3/9]: setting up reverse zone
   [4/9]: setting up our own record
   [5/9]: setting up kerberos principal
   [6/9]: setting up named.conf
   [7/9]: restarting named
   [8/9]: configuring named to start on boot
   [9/9]: changing resolv.conf to point to ourselves
done configuring named.
==
Setup complete


I did set my client with
[root@mtl-vdi01d ~]# ipa-client-install
--server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB
--realm=UNIX.CNPPD.LAB --mkhomedir
Discovery was successful!
Hostname: mtl-vdi01d.cn.ca 
Realm: UNIX.CNPPD.LAB
DNS Domain: UNIX.CNPPD.LAB
IPA Server: mtl-ipa01d.unix.cnppd.lab
BaseDN: dc=unix,dc=cnppd,dc=lab


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@unix.cnppd.lab:

Enrolled in IPA realm UNIX.CNPPD.LAB
Created /etc/ipa/default.conf
Configured[root@mtl-vdi01d ~]# ipa-client-install
--server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB
--realm=UNIX.CNPPD.LAB --mkhomedir
Discovery was successful!
Hostname: mtl-vdi01d.cn.ca 
Realm: UNIX.CNPPD.LAB
DNS Domain: UNIX.CNPPD.LAB
IPA Server: mtl-ipa01d.unix.cnppd.lab
BaseDN: dc=unix,dc=cnppd,dc=lab


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@unix.cnppd.lab:

Enrolled in IPA realm UNIX.CNPPD.LAB
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
SSSD enabled
Unable to find 'admin' user with 'getent passwd admin'!
Recognized configuration: SSSD
NTP enabled
Client configuration complete. /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
SSSD enabled
Unable to find 'admin' user with 'getent passwd admin'!
Recognized configuration: SSSD
NTP enabled
Client configuration complete.

you can see that ipa did enroll my client

[root@mtl-ipa01d ~]# ipa host-find
---
2 hosts matched
---
   Host name: mtl-ipa01d.unix.cnppd.lab
   Principal name: host/mtl-ipa01d.unix.cnppd@unix.cnppd.lab
   Keytab: True
   Password: False
   Managed by: mtl-ipa01d.unix.cnppd.lab

   Host name: mtl-vdi01d.cn.ca 
   Certificate:
MIIDhTCCAm2gAwIBAgIBDDANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5VTklYLkNOUFBELkxBQjEeMBwGA1UE

Re: [Freeipa-users] Fwd: manual client join

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 05:29 PM, Stephen Ingram wrote:
> On Tue, Mar 13, 2012 at 2:25 PM, Dmitri Pal  wrote:
>> Thank you!
>> Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do
>> the correct processing and handling when we triage them.
> Got it. Sorry about that. I guess that's why it was the default.
>
> Steve
NP.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fwd: manual client join

2012-03-13 Thread Stephen Ingram 
On Tue, Mar 13, 2012 at 2:25 PM, Dmitri Pal  wrote:
> Thank you!
> Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do
> the correct processing and handling when we triage them.

Got it. Sorry about that. I guess that's why it was the default.

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fwd: manual client join

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 04:44 PM, Stephen Ingram wrote:
> On Mon, Dec 19, 2011 at 5:36 AM, John Dennis  wrote:
>> Sorry, but currently on the command line the only way to specify a
>> certificate is via it's serial number. The serial number is the only
>> identifier guaranteed to be unique. However, I agree it's not convenient.
>> Would you like to open an RFE (Request for Enhancement) on
>> https://fedorahosted.org/freeipa/
> I know it's been some time, but I've opened a ticket. I've never
> submitted an RFE before so I'm not sure I filled in the correct
> selections. I went for less urgent as this really isn't breaking
> anything--it's just more of an inconvenience. It's ticket #2528.
>
> Steve
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Thank you!
Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do
the correct processing and handling when we triage them.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] manual client join

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 05:16 PM, Stephen Ingram wrote:
> On Sat, Dec 3, 2011 at 10:56 AM, Dmitri Pal  wrote:
>> On 11/30/2011 03:59 PM, Rob Crittenden wrote:
>>> Stephen Ingram wrote:
 Rob-

 On Wed, Nov 30, 2011 at 12:04 PM, Rob
 Crittenden  wrote:
> Retrieve the CA certificate for the FreeIPA CA.
>
> # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt
>
> Create a separate Kerberos configuration to test the provided
> credentials.
> This enables a Kerberos connection to the FreeIPA XML-RPC server,
> necessary
> to join the FreeIPA client to the FreeIPA domain. This Kerberos
> configuration is ultimately discarded.
>
> - Basically just copy a working krb5.conf to /etc/krb5.conf and set
> up sssd
> or nss_ldap as documented.
>
> # kinit admin
> # ipa-join -s ipa.example.com -b dc=example,dc=com
>
> Or if using a one-time password you can skip the kinit and do
>
> # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123
>
> ipa-join lets IPA know a host is enrolled and retrieves a host
> principal and
> stores it into /etc/krb5.keytab.
>
> Enable certmonger, retrieve an SSL server certificate, and install the
> certificate in /etc/pki/nssdb.
>
> # service messagebus start
> # service certmonger start
> # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
> /etc/ipa/ca.crt
> # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate -
> client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K
> host/client.example@example.com
>
> Disable the nscd daemon.
>
> # service nscd stop
> # chkconfig nscd off
 Thanks, but aren't some of these steps assuming that ipa-client has
 been installed on the system? For instance, instead of "# ipa-join -s
 ipa.example.com -b dc=example,dc=com -w Secret123", can't I instead
 use kadmin to retrieve the keytab and then securely copy it over to
 the client system? And, in the case of the ca.crt, if there if IPA
 itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I
 realize that I will lose functionality by not having ipa-client, but
 just trying to build a case for supporting legacy systems that I would
 never want to take the time to adapt ipa-client for.

 Steve
>>> The only part assuming that is ipa-join itself. IPA does not support
>>> the direct use of kadmin or kadmin.local. On a supported platform
>>> you'd run:
>>>
>>> # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p
>>> host/remote.example.com
>>>
>>> Then ship /tmp/remote.keytab to the machine and either use ktutil to
>>> combine it with /etc/krb5.keytab or replace krb5.keytab with it (and
>>> fix owner and permissions, and potentially SELinux context).
>>>
>>> certmonger gets its IPA configuration from /etc/ipa/default.conf. If
>>> you don't want or have certmonger then you can skip the CA bit
>>> altogether. Otherwise you'll need to copy in a working config.
>>>
>> Should any part of this be documented?
> This might be beyond what you are thinking, however, to me, one of the
> best things about FreeIPA is that because of how flexible you've made
> it, I can use as much or as little as I want. These sorts of "small
> steps" might also make it easier to integrate into non-Redhat/Fedora
> or non-Linux systems. I have compiled and tested the suggestions
> offered to me by Rob and put them into an attached text document that
> roughly corresponds to the current section 3.4 of the FreeIPA
> documentation. It's probably a little rough, but should make a nice
> template to help supplement the existing documentation.
>
> Steve
Thank you! We will take a look.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] need info on AD / IPA coexistence

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 02:59 PM, Sylvain Angers wrote:
>
>
> 2012/3/8 Brian Cook mailto:bc...@redhat.com>>
>
> Also, I would not use 'delegation record' from AD, use conditional
> forwarding for *.unix.abcd.ca .  Your AD
> admins should know how to do it.
>
> ---
> Brian Cook
> Solutions Architect, Red Hat, Inc.
> 407-212-7079 
>
>
>
>
> On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote:
>
>> On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote:
>>> Alright!
>>>
>>> I am now requesting to our DNS team
>>>
>>> please delegate dns zone "unix.abcd.ca " to ???
>>
>> the ip address of your ipa server, they will know what questions to
>> ask :)
>>
>>> Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca
>>>  or
>>> ipaserver.abcd.ca ?
>>
>>> does it matter?
>>
>> It does, the IPa server DNS domain is what matters for the first
>> master.
>> So it should be .unix.abcd.ca 
>>
>> So that DNS domain = unix.abcd.ca  and realm
>> = UNIX.ABCD.CA  (if you use
>> the standard configuration).
>>
>> Simo.
>>
>> -- 
>> Simo Sorce * Red Hat, Inc * New York
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com 
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> Hello
>
> Still have same issue "unable to find 'admin' user with 'getent passwd
> admin'!
>
> I redid both client and servers, no selinux,no firewall
>
> Our dns teams did set soa unix.cnppd.lab to point to my ipa server
>
> I had to put a manual entry in /etc/hosts
> 165.115.118.21  mtl-ipa01d.unix.cnppd.lab   mtl-ipa01d
>
>
> then did set my ipa server with the following
> *ipa-server-install -a xxx --hostname=mtl-ipa01d.unix.cnppd.lab -n
> unix.cnppd.lab -p x -r UNIX.CNPPD.LAB --setup-dns
> --forwarder=165.115.52.21--fowarder=165.115.51.21*
> Server host name [mtl-ipa01d.unix.cnppd.lab]:
>
> Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab
> The IPA Master Server will be configured with
> Hostname:mtl-ipa01d.unix.cnppd.lab
> IP address:  165.115.118.21
> Domain name: unix.cnppd.lab
>
> Do you want to configure the reverse zone? [yes]:
> Please specify the reverse zone name [118.115.165.in-addr.arpa.]:
> Using reverse zone 118.115.165.in-addr.arpa.
>
>
>
> Restarting the directory server
> Restarting the KDC
> Restarting the web server
> Configuring named:
>   [1/9]: adding DNS container
>   [2/9]: setting up our zone
>   [3/9]: setting up reverse zone
>   [4/9]: setting up our own record
>   [5/9]: setting up kerberos principal
>   [6/9]: setting up named.conf
>   [7/9]: restarting named
>   [8/9]: configuring named to start on boot
>   [9/9]: changing resolv.conf to point to ourselves
> done configuring named.
> ==
> Setup complete
>
>
> I did set my client with
> [root@mtl-vdi01d ~]# ipa-client-install
> --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB
> --realm=UNIX.CNPPD.LAB --mkhomedir
> Discovery was successful!
> Hostname: mtl-vdi01d.cn.ca 
> Realm: UNIX.CNPPD.LAB
> DNS Domain: UNIX.CNPPD.LAB
> IPA Server: mtl-ipa01d.unix.cnppd.lab
> BaseDN: dc=unix,dc=cnppd,dc=lab
>
>
> Continue to configure the system with these values? [no]: yes
> User authorized to enroll computers: admin
> Synchronizing time with KDC...
> Password for ad...@unix.cnppd.lab: 
>
> Enrolled in IPA realm UNIX.CNPPD.LAB
> Created /etc/ipa/default.conf
> Configured[root@mtl-vdi01d ~]# ipa-client-install
> --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB
> --realm=UNIX.CNPPD.LAB --mkhomedir
> Discovery was successful!
> Hostname: mtl-vdi01d.cn.ca 
> Realm: UNIX.CNPPD.LAB
> DNS Domain: UNIX.CNPPD.LAB
> IPA Server: mtl-ipa01d.unix.cnppd.lab
> BaseDN: dc=unix,dc=cnppd,dc=lab
>
>
> Continue to configure the system with these values? [no]: yes
> User authorized to enroll computers: admin
> Synchronizing time with KDC...
> Password for ad...@unix.cnppd.lab: 
>
> Enrolled in IPA realm UNIX.CNPPD.LAB
> Created /etc/ipa/default.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
> SSSD enabled
> Unable to find 'admin' user with 'getent passwd admin'!
> Recognized configuration: SSSD
> NTP enabled
> Client configuration complete. /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
> SSSD enabled
> Unable to find 'admin' user with 'getent passwd admin'!
> Recognized configuration: SSSD
> NTP enabled
> Client configuration complete.
>
> you can see that ipa did enroll my client 
>
> [root@mtl-ipa01d ~]# ipa host-find
> ---
> 2 hosts matched
> ---
>   Host name:

Re: [Freeipa-users] manual client join

2012-03-13 Thread Stephen Ingram 
On Sat, Dec 3, 2011 at 10:56 AM, Dmitri Pal  wrote:
> On 11/30/2011 03:59 PM, Rob Crittenden wrote:
>> Stephen Ingram wrote:
>>> Rob-
>>>
>>> On Wed, Nov 30, 2011 at 12:04 PM, Rob
>>> Crittenden  wrote:
 Retrieve the CA certificate for the FreeIPA CA.

 # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt

 Create a separate Kerberos configuration to test the provided
 credentials.
 This enables a Kerberos connection to the FreeIPA XML-RPC server,
 necessary
 to join the FreeIPA client to the FreeIPA domain. This Kerberos
 configuration is ultimately discarded.

 - Basically just copy a working krb5.conf to /etc/krb5.conf and set
 up sssd
 or nss_ldap as documented.

 # kinit admin
 # ipa-join -s ipa.example.com -b dc=example,dc=com

 Or if using a one-time password you can skip the kinit and do

 # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123

 ipa-join lets IPA know a host is enrolled and retrieves a host
 principal and
 stores it into /etc/krb5.keytab.

 Enable certmonger, retrieve an SSL server certificate, and install the
 certificate in /etc/pki/nssdb.

 # service messagebus start
 # service certmonger start
 # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
 /etc/ipa/ca.crt
 # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate -
 client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K
 host/client.example@example.com

 Disable the nscd daemon.

 # service nscd stop
 # chkconfig nscd off
>>>
>>> Thanks, but aren't some of these steps assuming that ipa-client has
>>> been installed on the system? For instance, instead of "# ipa-join -s
>>> ipa.example.com -b dc=example,dc=com -w Secret123", can't I instead
>>> use kadmin to retrieve the keytab and then securely copy it over to
>>> the client system? And, in the case of the ca.crt, if there if IPA
>>> itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I
>>> realize that I will lose functionality by not having ipa-client, but
>>> just trying to build a case for supporting legacy systems that I would
>>> never want to take the time to adapt ipa-client for.
>>>
>>> Steve
>>
>> The only part assuming that is ipa-join itself. IPA does not support
>> the direct use of kadmin or kadmin.local. On a supported platform
>> you'd run:
>>
>> # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p
>> host/remote.example.com
>>
>> Then ship /tmp/remote.keytab to the machine and either use ktutil to
>> combine it with /etc/krb5.keytab or replace krb5.keytab with it (and
>> fix owner and permissions, and potentially SELinux context).
>>
>> certmonger gets its IPA configuration from /etc/ipa/default.conf. If
>> you don't want or have certmonger then you can skip the CA bit
>> altogether. Otherwise you'll need to copy in a working config.
>>
>
> Should any part of this be documented?

This might be beyond what you are thinking, however, to me, one of the
best things about FreeIPA is that because of how flexible you've made
it, I can use as much or as little as I want. These sorts of "small
steps" might also make it easier to integrate into non-Redhat/Fedora
or non-Linux systems. I have compiled and tested the suggestions
offered to me by Rob and put them into an attached text document that
roughly corresponds to the current section 3.4 of the FreeIPA
documentation. It's probably a little rough, but should make a nice
template to help supplement the existing documentation.

Steve
3.4 Manual Configuring a Linux Client

The ipa-client-install command automatically configures services like Kerberos, 
SSSD, PAM and NSS. However, there are some situations where the 
ipa-client-install command cannot be used on a system, or, its full 
capabilities are simply not required. In those instances, the FreeIPA client 
entries and services can be configured manually.

The entire set of capabilities of FreeIPA can be obtained by installing and 
configuring SSSD and either using authconfig or editing the PAM configuration 
files by hand. In instances where only a subset of FreeIPA capabilities are 
desired, for example a Web service on a system using FreeIPA as an 
authentication source, only the necessary configuration changes need be 
implemented.

3.4.1 Retrieve CA Certificate from FreeIPA server

1. Retrieve CA certificate

# mkdir /etc/ipa

# wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt

2. import CA certificate

a. Using certutil (NSS):
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt

b. Using openssl:
   #  openssl x509 -in /etc/ipa/ca.crt -text >> /etc/pki/tls/certs/ca-bundle.crt


3.4.2 Obtain and Import Host Certificate

1. Generate CSR for client machine

a. Using certutil (NSS):
# certutil -R -s "CN=client.example.com,O=EXAMPLE.COM" -d /etc/pki/nssdb -a 
> client.

Re: [Freeipa-users] Fwd: manual client join

2012-03-13 Thread Stephen Ingram 
On Mon, Dec 19, 2011 at 5:36 AM, John Dennis  wrote:
> Sorry, but currently on the command line the only way to specify a
> certificate is via it's serial number. The serial number is the only
> identifier guaranteed to be unique. However, I agree it's not convenient.
> Would you like to open an RFE (Request for Enhancement) on
> https://fedorahosted.org/freeipa/

I know it's been some time, but I've opened a ticket. I've never
submitted an RFE before so I'm not sure I filled in the correct
selections. I went for less urgent as this really isn't breaking
anything--it's just more of an inconvenience. It's ticket #2528.

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] need info on AD / IPA coexistence

2012-03-13 Thread Sylvain Angers 
2012/3/8 Brian Cook 

> Also, I would not use 'delegation record' from AD, use conditional
> forwarding for *.unix.abcd.ca.  Your AD admins should know how to do it.
>
>  ---
> Brian Cook
> Solutions Architect, Red Hat, Inc.
> 407-212-7079
>
>
>
>
> On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote:
>
> On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote:
>
> Alright!
>
>
> I am now requesting to our DNS team
>
>
> please delegate dns zone "unix.abcd.ca" to ???
>
>
> the ip address of your ipa server, they will know what questions to
> ask :)
>
> Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or
>
> ipaserver.abcd.ca?
>
>
> does it matter?
>
>
> It does, the IPa server DNS domain is what matters for the first master.
> So it should be .unix.abcd.ca
>
> So that DNS domain = unix.abcd.ca and realm = UNIX.ABCD.CA (if you use
> the standard configuration).
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
Hello

Still have same issue "unable to find 'admin' user with 'getent passwd
admin'!

I redid both client and servers, no selinux,no firewall

Our dns teams did set soa unix.cnppd.lab to point to my ipa server

I had to put a manual entry in /etc/hosts
165.115.118.21  mtl-ipa01d.unix.cnppd.lab   mtl-ipa01d


then did set my ipa server with the following
*ipa-server-install -a xxx --hostname=mtl-ipa01d.unix.cnppd.lab -n
unix.cnppd.lab -p x -r UNIX.CNPPD.LAB --setup-dns
--forwarder=165.115.52.21--fowarder=165.115.51.21*
Server host name [mtl-ipa01d.unix.cnppd.lab]:

Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab
The IPA Master Server will be configured with
Hostname:mtl-ipa01d.unix.cnppd.lab
IP address:  165.115.118.21
Domain name: unix.cnppd.lab

Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [118.115.165.in-addr.arpa.]:
Using reverse zone 118.115.165.in-addr.arpa.


Restarting the directory server
Restarting the KDC
Restarting the web server
Configuring named:
  [1/9]: adding DNS container
  [2/9]: setting up our zone
  [3/9]: setting up reverse zone
  [4/9]: setting up our own record
  [5/9]: setting up kerberos principal
  [6/9]: setting up named.conf
  [7/9]: restarting named
  [8/9]: configuring named to start on boot
  [9/9]: changing resolv.conf to point to ourselves
done configuring named.
==
Setup complete


I did set my client with
[root@mtl-vdi01d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab
--domain=UNIX.CNPPD.LAB --realm=UNIX.CNPPD.LAB --mkhomedir
Discovery was successful!
Hostname: mtl-vdi01d.cn.ca
Realm: UNIX.CNPPD.LAB
DNS Domain: UNIX.CNPPD.LAB
IPA Server: mtl-ipa01d.unix.cnppd.lab
BaseDN: dc=unix,dc=cnppd,dc=lab


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@unix.cnppd.lab:

Enrolled in IPA realm UNIX.CNPPD.LAB
Created /etc/ipa/default.conf
Configured[root@mtl-vdi01d ~]# ipa-client-install
--server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB
--realm=UNIX.CNPPD.LAB --mkhomedir
Discovery was successful!
Hostname: mtl-vdi01d.cn.ca
Realm: UNIX.CNPPD.LAB
DNS Domain: UNIX.CNPPD.LAB
IPA Server: mtl-ipa01d.unix.cnppd.lab
BaseDN: dc=unix,dc=cnppd,dc=lab


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@unix.cnppd.lab:

Enrolled in IPA realm UNIX.CNPPD.LAB
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
SSSD enabled
Unable to find 'admin' user with 'getent passwd admin'!
Recognized configuration: SSSD
NTP enabled
Client configuration complete. /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB
SSSD enabled
Unable to find 'admin' user with 'getent passwd admin'!
Recognized configuration: SSSD
NTP enabled
Client configuration complete.

you can see that ipa did enroll my client

[root@mtl-ipa01d ~]# ipa host-find
---
2 hosts matched
---
  Host name: mtl-ipa01d.unix.cnppd.lab
  Principal name: host/mtl-ipa01d.unix.cnppd@unix.cnppd.lab
  Keytab: True
  Password: False
  Managed by: mtl-ipa01d.unix.cnppd.lab

  Host name: mtl-vdi01d.cn.ca
  Certificate:
MIIDhTCCAm2gAwIBAgIBDDANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5VTklYLkNOUFBELkxBQjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEyMDMxMzE4Mjc0MVoXDTE0MDMxNDE4Mjc0MVowNDEXMBUGA1UEChMOVU5JWC5DTlBQRC5MQUIxGTAXBgNVBAMTEG10bC12ZGkwMWQuY24uY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTPD8p7Ttxn87Y/2CCu54GDTd/CS77irN6OYj9IznqMusHAIWsVVu5m0aT77iULYzO9lKmKCL9RuSnZuqsoppFZk8UJu1KAGKv2FQi7zck28P2t6XRhHXcLRRTq5Mzfd/QjFmCv3oxTP2gd/0rLZUTHJkTzqyYIMlExfQqnEBJCzfzukyFUB5S+X2DthiGOM7vcKPXlmG

Re: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials

2012-03-13 Thread Petr Vobornik 

On 03/13/2012 02:26 PM, Simo Sorce wrote:

On Tue, 2012-03-13 at 13:37 +0100, Dimitris Tsompanidis wrote:

Hi,

I am deploying FreeIPA for the company I work for and it has been a good
experience so far, apart from the fact that users can not reset their
passwords throught the web UI.

Users use Firefox to log into their accounts, they can update their
contact details just fine, but when they try to reset their passwords,
they get "Insufficient access: Invalid credentials".
At one point, I restarted FreeIPA and a couple of users were able to
reset their passwords but the rest of them keep getting the same error.
However, when users ssh to a Suse server running Krb5 against FreeIPA,
the password change works either by getting the "password expired"
notice or by running kpasswd.
My guess is that I do something wrong in the user-creation procedure or
that I missed something in the default policy that I should know.

I could get over this by just using ssh for password resets but I'm
planning on activating business users' account in the near future and
ssh is definitely out of the question.
I should also point out that we're using FreeIPA only for authentication
on servers (SSH, Jira, etc) but not on the desktop machines and I'm
running FreeIPA 2.1.4-4 on Fedora16.

Any comments are appreciated.


Sorry Dimitris, unfortunately this is currently a limitation with our
webUI, password changes on password expiration do not work through the
webUI, and that's the default state when you create and give a first
password to new users.

Simo.




I'll just add, that user can change password in WebUI, but not after 
reset (as simo wrote).


In this case I think the message "Insufficient access: Invalid 
credentials" means that the password doesn't meet password policy 
requirements. It is a know bug in 2.1.x. It is fixed in 2.2.


https://fedorahosted.org/freeipa/ticket/2315
--
Petr Vobornik

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials

2012-03-13 Thread Dimitris Tsompanidis 


On 13/03/2012 14:26, Simo Sorce wrote:


Sorry Dimitris, unfortunately this is currently a limitation with our
webUI, password changes on password expiration do not work through the
webUI, and that's the default state when you create and give a first
password to new users.

Simo.

Although this also is a problem (in my book), I've learned to live with 
it and that's why I try to

1) set a default initial password as admin
2) change it myself by logging through the console as the user
3) give the 2nd temporary password to the user.
However, people still can not change to a new password through the web UI.

The process I use on the 2nd step is to ssh into another server as the 
user and do the password change there.




Also, Dmitri Pal mentioned

Do you set the password for the user after you create user account using
ipa passwd command?

I also tried this.
> kinit admin
> ipa passwd testuser
[temp pass #1]
> kinit testuser
> ipa passwd
[temp pass #2]

but the user still can not reset his password through the web UI.



Dimitris Tsompanidis
System administrator at ComeOn!
dimitris.tsompani...@comeon.com


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials

2012-03-13 Thread Simo Sorce 
On Tue, 2012-03-13 at 13:37 +0100, Dimitris Tsompanidis wrote:
> Hi,
> 
> I am deploying FreeIPA for the company I work for and it has been a good 
> experience so far, apart from the fact that users can not reset their 
> passwords throught the web UI.
> 
> Users use Firefox to log into their accounts, they can update their 
> contact details just fine, but when they try to reset their passwords, 
> they get "Insufficient access: Invalid credentials".
> At one point, I restarted FreeIPA and a couple of users were able to 
> reset their passwords but the rest of them keep getting the same error.
> However, when users ssh to a Suse server running Krb5 against FreeIPA, 
> the password change works either by getting the "password expired" 
> notice or by running kpasswd.
> My guess is that I do something wrong in the user-creation procedure or 
> that I missed something in the default policy that I should know.
> 
> I could get over this by just using ssh for password resets but I'm 
> planning on activating business users' account in the near future and 
> ssh is definitely out of the question.
> I should also point out that we're using FreeIPA only for authentication 
> on servers (SSH, Jira, etc) but not on the desktop machines and I'm 
> running FreeIPA 2.1.4-4 on Fedora16.
> 
> Any comments are appreciated.

Sorry Dimitris, unfortunately this is currently a limitation with our
webUI, password changes on password expiration do not work through the
webUI, and that's the default state when you create and give a first
password to new users.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 08:37 AM, Dimitris Tsompanidis wrote:
> Hi,
>
> I am deploying FreeIPA for the company I work for and it has been a
> good experience so far, apart from the fact that users can not reset
> their passwords throught the web UI.
>
> Users use Firefox to log into their accounts, they can update their
> contact details just fine, but when they try to reset their passwords,
> they get "Insufficient access: Invalid credentials".
> At one point, I restarted FreeIPA and a couple of users were able to
> reset their passwords but the rest of them keep getting the same error.
> However, when users ssh to a Suse server running Krb5 against FreeIPA,
> the password change works either by getting the "password expired"
> notice or by running kpasswd.
> My guess is that I do something wrong in the user-creation procedure
> or that I missed something in the default policy that I should know.
>
> I could get over this by just using ssh for password resets but I'm
> planning on activating business users' account in the near future and
> ssh is definitely out of the question.
> I should also point out that we're using FreeIPA only for
> authentication on servers (SSH, Jira, etc) but not on the desktop
> machines and I'm running FreeIPA 2.1.4-4 on Fedora16.
>
> Any comments are appreciated.
>
Do you set the password for the user after you create user account using
ipa passwd command?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Slight confusion about groups, netgroups, sudo rules etc.

2012-03-13 Thread Dmitri Pal 
On 03/13/2012 06:27 AM, Eivind Olsen wrote:
> Hello.
>
> I'm currently looking at implementing IPA in a mixed environment,
> consisting of RHEL6, RHEL5 and Solaris 10 systems. The IPA server(s) is
> the most recent one bundled with RHEL 6.2.
>
> I have some general rules I'll need to follow as best as I can, but I'm
> not really sure how to do this in IPA without it seeming like a huge
> work-around. This seems easy enough had it been for a pure RHEL6
> environment, but with Solaris there's no SSSD, I apparantly might need to
> downgrade the encryption types for "older" Solaris 10, etc. All of this is
> making my head dizzy, and I'd appreciate any help and pointers to clear my
> mind :)
>
> Examples of the basic rules are (there's more of them, it's not only for
> the DNS servers for example, but the other cases can be solved in the same
> way):
> - all sysadmins should be allowed to log into every system in the realm
> - all sysadmins should be allowed to run certain commands (or to make it
> easy, any command) through the use of "sudo", on all systems
> - some users will be part of certain groups, giving them permission to log
> into certain servers and run a set of commands through "sudo", for
> example: members of the dns-managers group should be allowed to ssh into
> the DNS servers (which consist of both RHEL6 and Solaris 10), and run
> certain commands through "sudo"
> - certain other users will be allowed to log into some systems, but
> without any additional access through "sudo" (the fact that they're
> allowed to log into system X doesn't mean they should be allowed to become
> root, etc).
>
> I've read a suggestion about making a host group for the Red Hat systems,
> a netgroup for the Solaris systems, and creating a user group which is
> added as a member of both the host group and netgroup. But, will I still
> need to worry about the old issue of Solaris apparantly not coping well
> with users that have >16 additional groups to their name?
>
> I have also read about having to add / change compatibility plugins,
> having to downgrade the algorithm for the Solaris 10 encryption type for
> older Solaris 10 releases, etc. And there's probably a few more things I
> need to watch out for and that aren't directly mentioned in the IPA
> documentation.
>
> Oh, in case it matters - there's no common NFS home directories, so I'll
> also need to automatically create the home directories (I've got this bit
> sorted on RHEL6 with help from oddjob-mkhomedir). For Solaris, I've read
> suggestions about using executable autofs maps to create home directories
> in /export/home and have tham loopback-mounted to /home so they match the
> homeDirectory attribute.
>

The following bug captures best of our knowledge about Solaris setups
https://bugzilla.redhat.com/show_bug.cgi?id=801883 so some of the info
from this bug might be helpful for you.
For the specific questions you ask above I will let more knowledgeable
people to chime in.

> Regards
> Eivind "Confused" Olsen
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials

2012-03-13 Thread Dimitris Tsompanidis 

Hi,

I am deploying FreeIPA for the company I work for and it has been a good 
experience so far, apart from the fact that users can not reset their 
passwords throught the web UI.


Users use Firefox to log into their accounts, they can update their 
contact details just fine, but when they try to reset their passwords, 
they get "Insufficient access: Invalid credentials".
At one point, I restarted FreeIPA and a couple of users were able to 
reset their passwords but the rest of them keep getting the same error.
However, when users ssh to a Suse server running Krb5 against FreeIPA, 
the password change works either by getting the "password expired" 
notice or by running kpasswd.
My guess is that I do something wrong in the user-creation procedure or 
that I missed something in the default policy that I should know.


I could get over this by just using ssh for password resets but I'm 
planning on activating business users' account in the near future and 
ssh is definitely out of the question.
I should also point out that we're using FreeIPA only for authentication 
on servers (SSH, Jira, etc) but not on the desktop machines and I'm 
running FreeIPA 2.1.4-4 on Fedora16.


Any comments are appreciated.

--
Dimitris Tsompanidis

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Slight confusion about groups, netgroups, sudo rules etc.

2012-03-13 Thread Eivind Olsen 
Hello.

I'm currently looking at implementing IPA in a mixed environment,
consisting of RHEL6, RHEL5 and Solaris 10 systems. The IPA server(s) is
the most recent one bundled with RHEL 6.2.

I have some general rules I'll need to follow as best as I can, but I'm
not really sure how to do this in IPA without it seeming like a huge
work-around. This seems easy enough had it been for a pure RHEL6
environment, but with Solaris there's no SSSD, I apparantly might need to
downgrade the encryption types for "older" Solaris 10, etc. All of this is
making my head dizzy, and I'd appreciate any help and pointers to clear my
mind :)

Examples of the basic rules are (there's more of them, it's not only for
the DNS servers for example, but the other cases can be solved in the same
way):
- all sysadmins should be allowed to log into every system in the realm
- all sysadmins should be allowed to run certain commands (or to make it
easy, any command) through the use of "sudo", on all systems
- some users will be part of certain groups, giving them permission to log
into certain servers and run a set of commands through "sudo", for
example: members of the dns-managers group should be allowed to ssh into
the DNS servers (which consist of both RHEL6 and Solaris 10), and run
certain commands through "sudo"
- certain other users will be allowed to log into some systems, but
without any additional access through "sudo" (the fact that they're
allowed to log into system X doesn't mean they should be allowed to become
root, etc).

I've read a suggestion about making a host group for the Red Hat systems,
a netgroup for the Solaris systems, and creating a user group which is
added as a member of both the host group and netgroup. But, will I still
need to worry about the old issue of Solaris apparantly not coping well
with users that have >16 additional groups to their name?

I have also read about having to add / change compatibility plugins,
having to downgrade the algorithm for the Solaris 10 encryption type for
older Solaris 10 releases, etc. And there's probably a few more things I
need to watch out for and that aren't directly mentioned in the IPA
documentation.

Oh, in case it matters - there's no common NFS home directories, so I'll
also need to automatically create the home directories (I've got this bit
sorted on RHEL6 with help from oddjob-mkhomedir). For Solaris, I've read
suggestions about using executable autofs maps to create home directories
in /export/home and have tham loopback-mounted to /home so they match the
homeDirectory attribute.

Regards
Eivind "Confused" Olsen


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha

2012-03-13 Thread Martin Kosek 
On Mon, 2012-03-12 at 13:41 -0600, Rich Megginson wrote:
> On 03/12/2012 01:39 PM, Dmitri Pal wrote:
> > On 03/12/2012 03:20 PM, Rich Megginson wrote:
> >> On 03/12/2012 12:40 PM, Dmitri Pal wrote:
> >>> On 03/12/2012 01:23 PM, Rich Megginson wrote:
>  On 03/12/2012 11:06 AM, Stephen Ingram wrote:
> > On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson
> > wrote:
> >> On 03/12/2012 01:34 AM, Martin Kosek wrote:
> >>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote:
>  On 03/11/2012 04:22 PM, Stephen Ingram wrote:
> > Now I've made it to the WebUI. Login works great (also via the new
> > form auth). Click on IPA Server tab and then Configuration yields:
> >
> > IPA Error 4208 - get-effective-rights: missing subject: Invalid
> > syntax
> >
> > This also happens at several other points in the UI. For example,
> > click one DNS zone and then the Settings tab within, or the Hosts
> > section within the Identity tab and clicking Settings. It seems
> > that
> > any attempt to configure settings yields this error.
> >
> > Directory server error logs point specifically to the NSACLPlugin:
> >
> > NSACLPlugin - get-effective-rights: missing subject
> > Failed to get effective rights for entry
> > (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21
> >
> > I'm guessing some incorrect ACLs?
> >
>  We will need to investigate.
>  Petr, Martin any idea?
> 
> >>> Looks like 389-ds can't parse/read the ACI. Rich, has anything
> >>> changed
> >>> in this area in F-17?
> >> F-17?  Nothing specific to F-17.  Is this error with the latest
> >> 1.2.10.2 or
> >> .3 in F-17 updates or updates-testing?
> > I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from
> > freeipa-devel repo.
>  This error means there is an empty GER control value sent with the
>  request.  Did the client code change recently?
>  ipaserver/plugins/ldap2.py get_effective_rights() looks correct
> >>> openldap?
> >> could be - or could be python-ldap related - python-ldap 2.4 switched
> >> to using pyasn1 to do some encoding that used to be done by the ldap
> >> library.
> > How can we check?
> You can use the debug flag in python-ldap when creating the ldap connection

I did some more poking in this issue and I found that the problem is in
new python-ldap library in F-17. When I updated this component to
python-ldap-2.4.6-2.fc17.x86_64 I got the very same error.

This is the BZ against python-ldap that I filed:
https://bugzilla.redhat.com/show_bug.cgi?id=802675

I have a Python script that can reproduce this issue in a much less
complicated environment (attached).

Martin
#!/usr/bin/python

import ldap

HOST = "ldap://vm-068.idm.lab.bos.redhat.com";
USER_DN = "uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com"
USER_PWD = "kokos123"


conn = ldap.initialize(HOST)
conn.simple_bind_s(USER_DN, USER_PWD)

print "test search"
conn.search_s(USER_DN, ldap.SCOPE_BASE, '(objectClass=*)', ['cn'])

print "test search with effective rights control"
sctrl = [ldap.controls.LDAPControl("1.3.6.1.4.1.42.2.27.9.5.2", True, "dn: %s" % USER_DN)]
conn.set_option(ldap.OPT_SERVER_CONTROLS, sctrl)
conn.search_s(USER_DN, ldap.SCOPE_BASE, '(objectClass=*)', ['cn'])
conn.set_option(ldap.OPT_SERVER_CONTROLS, [])
conn.unbind_s()

print "TEST OK"
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automount questions

2012-03-13 Thread Ondrej Valousek 



Right, currently this affects direct maps only. With SSSD integration,
there's one extra glitch that if automounter starts before SSSD does,
the automounter only gets "Connection refused" from the sss module and
does not retry reading the maps.


That's nasty and should be probably fixed. I can imagine having to restart sssd for whatever reason - autofs should be able to handle this 
elegantly (i.e. retry connection).


--

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s).
Please direct any additional queries to: communicati...@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automount questions

2012-03-13 Thread Jakub Hrozek 
On Tue, Mar 13, 2012 at 09:52:04AM +0100, Ondrej Valousek wrote:
>  You need to send SIGHUP to the deamon to force rereading of a map. When
>  I was working on the autofs/sssd integration effort, we spoke briefly
>  with Ian about possibilities of better ways to reread a map, but nothing
>  has surfaced yet.
> 
> 
>I do not have such an experience. For me, there is no need to restart
>autofs to make it aware of the new automount key. But I am using indirect
>maps only.

Right, currently this affects direct maps only. With SSSD integration,
there's one extra glitch that if automounter starts before SSSD does,
the automounter only gets "Connection refused" from the sss module and
does not retry reading the maps.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automount questions

2012-03-13 Thread Ondrej Valousek 



You need to send SIGHUP to the deamon to force rereading of a map. When
I was working on the autofs/sssd integration effort, we spoke briefly
with Ian about possibilities of better ways to reread a map, but nothing
has surfaced yet.

I do not have such an experience. For me, there is no need to restart autofs to make it aware of the new automount key. But I am using 
indirect maps only.

Third question: is it safe to restart the autofs service when people have
mounted shares on a client?

The short answer is yes, long answer is it depends :-)
It depends, exactly. Be especially cautious when updating automount package. Yum usually restarts the daemon as the last step - and 
sometimes it happens that the daemon crashes with a core dump instead of exiting normally. It that happens, all user shells lose information 
about the current working directory which can cause funny behaviour.


Ondrej

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s).
Please direct any additional queries to: communicati...@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users