Re: [Freeipa-users] Reinstalling a host without deleting
On Tue, November 15, 2011 00:40, Dan Scott wrote: > Hi, > > > Is there a 'nice' way to reinstall a host? i.e. The host has already > been installed in FreeIPA and for whatever reason I need to reinstall the OS, > so I have a clean > system and the host is already enrolled on the server. > > ipa-client-install fails with "Host already enrolled" and I have to connect > to an enrolled client, > remove the host, and then return to install the client. > > Would it be possible to have a '--reinstall' option to > ipa-client-install? It wouldn't have to add the host into IPA, just configure > the files and get the > keytab. > > Looking at the manpage, maybe I'm just looking for the --force option > to force the config files, and ipa-getkeytab. Is there anything else I need > to do? > If you run "ipa host-diable " or click on "Unprovision" in the webUI before re-installing, then the host can be enrolled using the same IPA host account. Rgds, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Reinstalling a host without deleting
On 11/14/2011 06:40 PM, Dan Scott wrote: > Hi, > > Is there a 'nice' way to reinstall a host? i.e. The host has already > been installed in FreeIPA and for whatever reason I need to reinstall > the OS, so I have a clean system and the host is already enrolled on > the server. > > ipa-client-install fails with "Host already enrolled" and I have to > connect to an enrolled client, remove the host, and then return to > install the client. > > Would it be possible to have a '--reinstall' option to > ipa-client-install? It wouldn't have to add the host into IPA, just > configure the files and get the keytab. > > Looking at the manpage, maybe I'm just looking for the --force option > to force the config files, and ipa-getkeytab. Is there anything else I > need to do? > > Thanks, > > Dan > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > Opened a ticket: https://fedorahosted.org/freeipa/ticket/2106 -- 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] fixing port numbers associated with the NIS
On Mon, Nov 14, 2011 at 05:19:44PM -0500, Boris Epstein wrote: >Hello all, > >I am using the FreeIPA to run NIS via a plugin. Works great - except >that the ypserv port numbers end up different after every reboot. That >makes it hard to run it with the firewall activated. > >Does anybody know how to make those port number assignments permanent? There's no tooling specifically for doing this, but the plugin supports it. In order to get it to use a fixed port, you'll need to edit the directory server entry for "cn=NIS Server, cn=plugins, cn=config" and add a "nsslapd-pluginarg0" value which contains the port number you'd like it to use. You can do this either by stopping the directory server, editing its dse.ldif file directly, and then restarting it, or by editing the entry "live" using ldapmodify and then restarting the server. The latter method (I'm using port 541 here) looks something like this: # ldapmodify -x -D "cn=Directory Manager" -W <<- EOF dn: cn=NIS Server,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: 541 - EOF # ipactl restart You'll need to supply the Directory Manager password. Once that's done, running "rpcinfo -p" on the server should show that the NIS service is listening on the desired port. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Reinstalling a host without deleting
Hi, Is there a 'nice' way to reinstall a host? i.e. The host has already been installed in FreeIPA and for whatever reason I need to reinstall the OS, so I have a clean system and the host is already enrolled on the server. ipa-client-install fails with "Host already enrolled" and I have to connect to an enrolled client, remove the host, and then return to install the client. Would it be possible to have a '--reinstall' option to ipa-client-install? It wouldn't have to add the host into IPA, just configure the files and get the keytab. Looking at the manpage, maybe I'm just looking for the --force option to force the config files, and ipa-getkeytab. Is there anything else I need to do? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] fixing port numbers associated with the NIS
Hello all, I am using the FreeIPA to run NIS via a plugin. Works great - except that the ypserv port numbers end up different after every reboot. That makes it hard to run it with the firewall activated. Does anybody know how to make those port number assignments permanent? Thanks. Boris. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Delete host: Unable to communicate with CMS (Not Found)
Hi, I receive the following error when I try to remove a host from IPA: djscott@pc35:~$ ipa host-del pc60 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) I'm running a Fedora 16 (freeipa-server-2.1.3-5.fc16.x86_64) server replicated with a Fedora 15 (freeipa-server-2.1.3-2.fc15.i686) server. I've looked at this: https://fedorahosted.org/freeipa/ticket/1889 But it looks like it was fixed in 2.1.2 or 2.1.3. Any ideas for what I need to do? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
On Mon, 14 Nov 2011, Dan Scott wrote: > >> > Loaded: error (Reason: No such file or directory) > >> > Active: inactive (dead) > >> Right - see http://directory.fedoraproject.org/wiki/Howto:systemd#FAQ > > Yes, the target is dirsrv.target, not dirsrv.service, while instances > > are dirsrv@NAME.service. That is life. > > :) Nice and consistent with other 'services'. Do you know if it's > possible for 'systemctl status dirsrv.service' to return nothing, > instead of saying that it's dead? This would help reduce the > confusion. No, this is 'as designed' behaviour of systemd -- it loads list of services it knows once and then answers negatively to anything else unless it knows the service. I think the idea was to make targets as synchronization points to which other services can rely in their ordering. As there is no single dirsrv.service, dirsrv.target is used to allow behaviour close to 'service dirsrv ' > > before, the keytab should be in place already and with proper > > ownership (dirsrv:dirsrv). > > Thanks. I'd just figured this out and fixed my /etc/sysconfig/dirsrv > file. The two servers seem to be working and syncing now. > > I've run into something else now though: > > djscott@pc35:~$ ipa host-del pc60 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Not Found) > > Could this be related? Or should I start a new thread to try and solve it. https://bugzilla.redhat.com/show_bug.cgi?id=741458 Please start new thread. This most likely something that Dogtag expects in Fedora 16 which wasn't persisting from old install, as in bug #741458. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
Hi, On Mon, Nov 14, 2011 at 15:50, Alexander Bokovoy wrote: > On Mon, 14 Nov 2011, Rich Megginson wrote: >> >replaced EXAMPLE-COM above and re-replaced it in the output below): >> > >> >[root@fileserver1 ~]# ls -l /etc/systemd/system/dirsrv.target.wants >> >total 0 >> >lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@EXAMPLE-COM.service -> >> >/etc/systemd/system/dirsrv@.service >> >lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@PKI-IPA.service -> >> >/etc/systemd/system/dirsrv@.service >> >[root@fileserver1 ~]# systemctl status dirsrv.service >> >dirsrv.service >> > Loaded: error (Reason: No such file or directory) >> > Active: inactive (dead) >> Right - see http://directory.fedoraproject.org/wiki/Howto:systemd#FAQ > Yes, the target is dirsrv.target, not dirsrv.service, while instances > are dirsrv@NAME.service. That is life. :) Nice and consistent with other 'services'. Do you know if it's possible for 'systemctl status dirsrv.service' to return nothing, instead of saying that it's dead? This would help reduce the confusion. > systemctl start dirsrv.target > > now would bring both instances up -- when you'll solve > kerberos credentials access. > >> >[root@fileserver1 ~]# >> > >> >My /var/log/dirsrv/slapd-EXAMPLE-COM/errors now contains: >> > >> >[14/Nov/2011:14:55:16 -0500] set_krb5_creds - Could not get initial >> >credentials for principal [ldap/fileserver1.example@example.com] >> >in keytab [WRFILE:/etc/krb5.keytab]: 13 (Permission denied) >> >[14/Nov/2011:14:55:16 -0500] slapd_ldap_sasl_interactive_bind - Error: >> >could not perform interactive bind for id [] mech [GSSAPI]: error -2 >> >(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >> >GSS failure. Minor code may provide more information (Credentials >> >cache file '/tmp/krb5cc_494' not found)) >> >[14/Nov/2011:14:55:16 -0500] slapi_ldap_bind - Error: could not >> >perform interactive bind for id [] mech [GSSAPI]: error -2 (Local >> >error) >> > >> >And the permissions on /etc/krb5.keytab: >> > >> >[root@fileserver1 ~]# ls -Z /etc/krb5.keytab >> >-rw---. root root unconfined_u:object_r:krb5_keytab_t:s0 >> >/etc/krb5.keytab >> Right - directory server usually runs as dirsrv:dirsrv not root:root >> - not sure what is responsible for ensuring the krb5.keytab is owned >> by the dirsrv user. > It should be /etc/dirsrv/ds.keytab, not /etc/krb5.keytab. Could you > please show your /etc/sysconfig/dirsrv? KRB5_KTNAME there should point > to /etc/dirsrv/ds.keytab and as you have installation that worked > before, the keytab should be in place already and with proper > ownership (dirsrv:dirsrv). Thanks. I'd just figured this out and fixed my /etc/sysconfig/dirsrv file. The two servers seem to be working and syncing now. I've run into something else now though: djscott@pc35:~$ ipa host-del pc60 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Could this be related? Or should I start a new thread to try and solve it. > Dan, could you please file a bug against freeipa in Fedora 16 to ask > about upgrade from Fedora 15. I'll then work out the script and how to use > it. I'm not sure it will be possible to use it in %post for upgrades > but at least running it after yum upgrade would be possible. Sure, will do. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sssd not updating reverse dns
On 11/14/2011 01:40 PM, Stephen Gallagher wrote: On Sun, 2011-11-13 at 19:19 +0100, Sigbjorn Lie wrote: On 11/13/2011 02:48 PM, Simo Sorce wrote: On Sat, 2011-11-12 at 15:55 +0100, Sigbjorn Lie wrote: Hi, I notice that when sssd is configured to update DNS, it's only updating the DNS forward zone, it's not updating the DNS reverse zone. And I cannot find any option for enabling updating of the reverse dns zone. Have I missed something? Or is updating the reverse zone not supported? It is not supported at this time. While we have a way to determine if your host has any right to update the machine A/ name because we can check if the host authenticated using a key of type host/@REALM we have no way to validate that a host has any right to update a PTR record. Allowing a host to change any PTR record in any reverse zone would be very disruptive as a compromised host could change PTR records for important servers. Ok, I see the issue. I notice ISC dhcpd adds a TXT record along with the updated record with a string that identifies that host record being "owned" by that dhcpd. And it does not attempt to update DNS if it cannot validate the content of the TXT record, or there already exists a record without a corresponding TXT record. Perhaps a similar approach could be applied to IPA? Using attributes in the LDAP DNS tree instead of TXT records.. ? SSSD doesn't user LDAP in any way while updating the DNS records. We actually just use GSS-TSIG to speak directly to the DNS server. We suggested using XML-RPC communication to the FreeIPA server at one point, but we decided that it was probably for the best to just stick with the standardized approach for now. The flip side of this is, of course, that we cannot update the PTR records (due to the security risks that Simo pointed out). So maybe we should consider putting this back on the table. We are trying to make sure (patches, configurations) that reverse resolution is disabled for kerberos and canonicalization does not use it by default as it is unreliable in any case. Yes, I've noticed. :) Authentication based on forward/reverse lookups aside, being able to look up reverse IP records does help troubleshooting. And it becomes almost a requirement for being able to manage IPv6 networks. It would be very nice to see reverse address update implemented in SSSD at some point. Is there already an open RFE? There is no RFE for this yet. Please feel free to open one at https://fedorahosted.org/sssd How about an option in SSSD for reverse update using the same GSS-TSIG, but turned off by default? IPA seem to ready for this by setting the "BIND update policy" and Dynamic update options under DNS -> reverse-zone -> Settings ? Hopefully the admin would configure the dhcp dynamic ip range outside of where he placed the servers, or have the clients on a different subnet than the servers. Where the server reverse zone can be disabled for dynamic updates, and the client reverse zone can be enabled for dynamic updates. At least having the option would be great. :) Besides, if the admin manages to configure his dhcp server so that duplicate IP address allocation occour, reverse dns will be the least of his problems. :) Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
On Mon, 14 Nov 2011, Rich Megginson wrote: > >replaced EXAMPLE-COM above and re-replaced it in the output below): > > > >[root@fileserver1 ~]# ls -l /etc/systemd/system/dirsrv.target.wants > >total 0 > >lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@EXAMPLE-COM.service -> > >/etc/systemd/system/dirsrv@.service > >lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@PKI-IPA.service -> > >/etc/systemd/system/dirsrv@.service > >[root@fileserver1 ~]# systemctl status dirsrv.service > >dirsrv.service > > Loaded: error (Reason: No such file or directory) > > Active: inactive (dead) > Right - see http://directory.fedoraproject.org/wiki/Howto:systemd#FAQ Yes, the target is dirsrv.target, not dirsrv.service, while instances are dirsrv@NAME.service. That is life. systemctl start dirsrv.target now would bring both instances up -- when you'll solve kerberos credentials access. > >[root@fileserver1 ~]# > > > >My /var/log/dirsrv/slapd-EXAMPLE-COM/errors now contains: > > > >[14/Nov/2011:14:55:16 -0500] set_krb5_creds - Could not get initial > >credentials for principal [ldap/fileserver1.example@example.com] > >in keytab [WRFILE:/etc/krb5.keytab]: 13 (Permission denied) > >[14/Nov/2011:14:55:16 -0500] slapd_ldap_sasl_interactive_bind - Error: > >could not perform interactive bind for id [] mech [GSSAPI]: error -2 > >(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > >GSS failure. Minor code may provide more information (Credentials > >cache file '/tmp/krb5cc_494' not found)) > >[14/Nov/2011:14:55:16 -0500] slapi_ldap_bind - Error: could not > >perform interactive bind for id [] mech [GSSAPI]: error -2 (Local > >error) > > > >And the permissions on /etc/krb5.keytab: > > > >[root@fileserver1 ~]# ls -Z /etc/krb5.keytab > >-rw---. root root unconfined_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab > Right - directory server usually runs as dirsrv:dirsrv not root:root > - not sure what is responsible for ensuring the krb5.keytab is owned > by the dirsrv user. It should be /etc/dirsrv/ds.keytab, not /etc/krb5.keytab. Could you please show your /etc/sysconfig/dirsrv? KRB5_KTNAME there should point to /etc/dirsrv/ds.keytab and as you have installation that worked before, the keytab should be in place already and with proper ownership (dirsrv:dirsrv). Dan, could you please file a bug against freeipa in Fedora 16 to ask about upgrade from Fedora 15. I'll then work out the script and how to use it. I'm not sure it will be possible to use it in %post for upgrades but at least running it after yum upgrade would be possible. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] importing old NIS passwd/group maps into Free IPA
On 11/14/2011 04:33 PM, Dmitri Pal wrote: On 11/11/2011 05:12 PM, Boris Epstein wrote: Hello all, The question is in the subject. Is there an established reliable way of doing that? Thanks. Boris. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/migrating-from-nis.html This is so far what we have. I also wrote some scripts that will migrate the hosts, passwd, group, group members, and netgroup NIS maps into IPA a few months ago: https://www.redhat.com/archives/freeipa-users/2011-April/msg7.html The automount maps can be imported using the ipa command: "ipa automountlocation-import". Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
On 11/14/2011 01:08 PM, Dan Scott wrote:
Hi,
On Mon, Nov 14, 2011 at 13:06, Alexander Bokovoy wrote:
On Mon, 14 Nov 2011, Dan Scott wrote:
In any case, the process is still failing to start. Do I need to
create a link in dirsrv.target.wants to somewhere?
You need to do some steps like ipa-server-install does. I'm trying to
get them separated in a small upgrade script but something like
following needs to be done, completely untested, may eat your kitten,
and realm/dirsrv instance names need to be replaced before running:
#! /usr/bin/python -E
from ipaserver.install.krbinstance import update_val_in_file
from ipapython import ipautil
from ipapython import services as ipaservices
# 1. Upgrade /etc/sysconfig/dirsrv for systemd
update_key_val_in_file("/etc/sysconfig/dirsrv", "KRB5_KTNAME",
"/etc/dirsrv/ds.keytab")
update_key_val_in_file("/etc/sysconfig/dirsrv", "export KRB5_KTNAME",
"/etc/dirsrv/ds.keytab")
# 2. Upgrade /etc/sysconfig/krb5kdc for systemd
replacevars = {'KRB5REALM':"EXAMPLE.COM"}
appendvars = {}
ipautil.config_replace_variables("/etc/sysconfig/krb5kdc",
replacevars=replacevars, appendvars=appendvars)
ipaservices.restore_context("/etc/sysconfig/krb5kdc")
# 3. Enable DS instances:
ipaservices.knownservices.dirsrv.enable("EXAMPLE-COM")
ipaservices.knownservices.dirsrv.enable("PKI-IPA")
# 4. Enable FreeIPA
ipaservices.knownservices.ipa.enable()
---
Note that these .enable() calls on Fedora 16 do much more than just
'systemctl enable foo.service', they copy and modify service files,
create symlinks and so on, all the dirty work required by systemd.
You may look at ipapython/platform/fedora16.py and systemd.py for
details.
OK, looks like I'm getting there, but there's still a problem (I
replaced EXAMPLE-COM above and re-replaced it in the output below):
[root@fileserver1 ~]# ls -l /etc/systemd/system/dirsrv.target.wants
total 0
lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@EXAMPLE-COM.service ->
/etc/systemd/system/dirsrv@.service
lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@PKI-IPA.service ->
/etc/systemd/system/dirsrv@.service
[root@fileserver1 ~]# systemctl status dirsrv.service
dirsrv.service
Loaded: error (Reason: No such file or directory)
Active: inactive (dead)
Right - see http://directory.fedoraproject.org/wiki/Howto:systemd#FAQ
[root@fileserver1 ~]#
My /var/log/dirsrv/slapd-EXAMPLE-COM/errors now contains:
[14/Nov/2011:14:55:16 -0500] set_krb5_creds - Could not get initial
credentials for principal [ldap/fileserver1.example@example.com]
in keytab [WRFILE:/etc/krb5.keytab]: 13 (Permission denied)
[14/Nov/2011:14:55:16 -0500] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: error -2
(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (Credentials
cache file '/tmp/krb5cc_494' not found))
[14/Nov/2011:14:55:16 -0500] slapi_ldap_bind - Error: could not
perform interactive bind for id [] mech [GSSAPI]: error -2 (Local
error)
And the permissions on /etc/krb5.keytab:
[root@fileserver1 ~]# ls -Z /etc/krb5.keytab
-rw---. root root unconfined_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
Right - directory server usually runs as dirsrv:dirsrv not root:root -
not sure what is responsible for ensuring the krb5.keytab is owned by
the dirsrv user.
The permissions are the same on my other, replica, IPA server (which
is still Fedora 15). The other message above is correct:
/tmp/krb5cc_494 does not exist.
Thanks,
Dan
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
Hi,
On Mon, Nov 14, 2011 at 13:06, Alexander Bokovoy wrote:
> On Mon, 14 Nov 2011, Dan Scott wrote:
>> In any case, the process is still failing to start. Do I need to
>> create a link in dirsrv.target.wants to somewhere?
> You need to do some steps like ipa-server-install does. I'm trying to
> get them separated in a small upgrade script but something like
> following needs to be done, completely untested, may eat your kitten,
> and realm/dirsrv instance names need to be replaced before running:
>
> #! /usr/bin/python -E
> from ipaserver.install.krbinstance import update_val_in_file
> from ipapython import ipautil
> from ipapython import services as ipaservices
>
> # 1. Upgrade /etc/sysconfig/dirsrv for systemd
> update_key_val_in_file("/etc/sysconfig/dirsrv", "KRB5_KTNAME",
> "/etc/dirsrv/ds.keytab")
> update_key_val_in_file("/etc/sysconfig/dirsrv", "export KRB5_KTNAME",
> "/etc/dirsrv/ds.keytab")
> # 2. Upgrade /etc/sysconfig/krb5kdc for systemd
> replacevars = {'KRB5REALM':"EXAMPLE.COM"}
> appendvars = {}
> ipautil.config_replace_variables("/etc/sysconfig/krb5kdc",
> replacevars=replacevars, appendvars=appendvars)
> ipaservices.restore_context("/etc/sysconfig/krb5kdc")
> # 3. Enable DS instances:
> ipaservices.knownservices.dirsrv.enable("EXAMPLE-COM")
> ipaservices.knownservices.dirsrv.enable("PKI-IPA")
> # 4. Enable FreeIPA
> ipaservices.knownservices.ipa.enable()
> ---
>
> Note that these .enable() calls on Fedora 16 do much more than just
> 'systemctl enable foo.service', they copy and modify service files,
> create symlinks and so on, all the dirty work required by systemd.
> You may look at ipapython/platform/fedora16.py and systemd.py for
> details.
OK, looks like I'm getting there, but there's still a problem (I
replaced EXAMPLE-COM above and re-replaced it in the output below):
[root@fileserver1 ~]# ls -l /etc/systemd/system/dirsrv.target.wants
total 0
lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@EXAMPLE-COM.service ->
/etc/systemd/system/dirsrv@.service
lrwxrwxrwx. 1 root root 35 Nov 14 14:49 dirsrv@PKI-IPA.service ->
/etc/systemd/system/dirsrv@.service
[root@fileserver1 ~]# systemctl status dirsrv.service
dirsrv.service
Loaded: error (Reason: No such file or directory)
Active: inactive (dead)
[root@fileserver1 ~]#
My /var/log/dirsrv/slapd-EXAMPLE-COM/errors now contains:
[14/Nov/2011:14:55:16 -0500] set_krb5_creds - Could not get initial
credentials for principal [ldap/fileserver1.example@example.com]
in keytab [WRFILE:/etc/krb5.keytab]: 13 (Permission denied)
[14/Nov/2011:14:55:16 -0500] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: error -2
(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (Credentials
cache file '/tmp/krb5cc_494' not found))
[14/Nov/2011:14:55:16 -0500] slapi_ldap_bind - Error: could not
perform interactive bind for id [] mech [GSSAPI]: error -2 (Local
error)
And the permissions on /etc/krb5.keytab:
[root@fileserver1 ~]# ls -Z /etc/krb5.keytab
-rw---. root root unconfined_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
The permissions are the same on my other, replica, IPA server (which
is still Fedora 15). The other message above is correct:
/tmp/krb5cc_494 does not exist.
Thanks,
Dan
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
On Mon, 14 Nov 2011, Dan Scott wrote:
> > Could you make sure 'systemctl start dirsrv.target' actually starts
> > slapd for EXAMPLE-COM? If not, please show output of
> >
> > ls -l /etc/systemd/system/dirsrv.target.wants
>
> 'systemctl start dirsrv.target' doesn't appear to do anything, nothing
> shown on the command line and the logs don't change. The directory is
> empty:
>
> [root@fileserver1 schema]# ls -l /etc/systemd/system/dirsrv.target.wants/
> total 0
Yes, as I expected (below).
> > It may be that we would need to make a small upgrade script that
> > re-installs proper systemd instances for dirsrv.target as those are
> > produced during ipa-server-install and cannot be done automatically on
> > upgrade without proper intervention yet.
>
> Is this related to this:
> https://fedoraproject.org/wiki/Common_F16_bugs#Upgrade_from_previous_releases_resets_the_enablement_status_of_services
>
> Or is it to do with the dependencies of FreeIPA startup?
It is mixture of those cases. systemd is more complicated and if in
F15 we were able to get away via SystemV emulation, in F16 dirsrv migrated
natively to systemd, managing instances through native systemd
mechanism (dirsrv@EXAMPLE-COM.service as a service name, for
example).
This new mechanism is not accessible via SystemV emulation and we had
to migrate to systemd as well -- which means ipa-server-install
creates proper links and edits systemd service files as needed.
In addition, systemd does not really support our model of enabling
services, as systemd is per-host while we need to replicate service
state to multiple replicas. Thus, we do some of enable/disable/restart
management in ipactl.
> In any case, the process is still failing to start. Do I need to
> create a link in dirsrv.target.wants to somewhere?
You need to do some steps like ipa-server-install does. I'm trying to
get them separated in a small upgrade script but something like
following needs to be done, completely untested, may eat your kitten,
and realm/dirsrv instance names need to be replaced before running:
#! /usr/bin/python -E
from ipaserver.install.krbinstance import update_val_in_file
from ipapython import ipautil
from ipapython import services as ipaservices
# 1. Upgrade /etc/sysconfig/dirsrv for systemd
update_key_val_in_file("/etc/sysconfig/dirsrv", "KRB5_KTNAME",
"/etc/dirsrv/ds.keytab")
update_key_val_in_file("/etc/sysconfig/dirsrv", "export KRB5_KTNAME",
"/etc/dirsrv/ds.keytab")
# 2. Upgrade /etc/sysconfig/krb5kdc for systemd
replacevars = {'KRB5REALM':"EXAMPLE.COM"}
appendvars = {}
ipautil.config_replace_variables("/etc/sysconfig/krb5kdc",
replacevars=replacevars, appendvars=appendvars)
ipaservices.restore_context("/etc/sysconfig/krb5kdc")
# 3. Enable DS instances:
ipaservices.knownservices.dirsrv.enable("EXAMPLE-COM")
ipaservices.knownservices.dirsrv.enable("PKI-IPA")
# 4. Enable FreeIPA
ipaservices.knownservices.ipa.enable()
---
Note that these .enable() calls on Fedora 16 do much more than just
'systemctl enable foo.service', they copy and modify service files,
create symlinks and so on, all the dirty work required by systemd.
You may look at ipapython/platform/fedora16.py and systemd.py for
details.
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 failing to start dirsrv process
Hi, On Mon, Nov 14, 2011 at 10:19, Alexander Bokovoy wrote: > On Mon, 14 Nov 2011, Dan Scott wrote: > >> Hi, >> >> I've just upgraded a server from Fedora 15 to 16 and I'm having >> problems starting the dirsrv process: >> >> /var/log/messages >> Nov 14 09:38:27 fileserver1 ipactl[1351]: Failed to read data from >> Directory Service: Unknown error when retrieving list of services from >> LDAP: [Errno 2] No such file or directory >> Nov 14 09:38:27 fileserver1 ipactl[1351]: Shutting down >> Nov 14 09:38:27 fileserver1 ipactl[1351]: Starting Directory Service >> Nov 14 09:38:27 fileserver1 systemd[1]: ipa.service: main process >> exited, code=exited, status=1 >> Nov 14 09:38:27 fileserver1 systemd[1]: Unit ipa.service entered failed >> state. >> >> The /var/log/dirsrv/slapd-EXAMPLE-COM/errors file contains no new >> entries since Friday 11th. >> >> Any ideas how I can get this fixed? How can I find out which 'file or >> directory' is missing? > Looks like LDAP socket is not yet available at the time we try to > contact it. I think this was fixed in Fedora 16 package with this > patch: > http://git.fedorahosted.org/git/?p=freeipa.git;a=commitdiff;h=5451328bc55fe964c61e7b87959310f9c6748cf8 > > Could you make sure 'systemctl start dirsrv.target' actually starts > slapd for EXAMPLE-COM? If not, please show output of > > ls -l /etc/systemd/system/dirsrv.target.wants 'systemctl start dirsrv.target' doesn't appear to do anything, nothing shown on the command line and the logs don't change. The directory is empty: [root@fileserver1 schema]# ls -l /etc/systemd/system/dirsrv.target.wants/ total 0 > It may be that we would need to make a small upgrade script that > re-installs proper systemd instances for dirsrv.target as those are > produced during ipa-server-install and cannot be done automatically on > upgrade without proper intervention yet. Is this related to this: https://fedoraproject.org/wiki/Common_F16_bugs#Upgrade_from_previous_releases_resets_the_enablement_status_of_services Or is it to do with the dependencies of FreeIPA startup? In any case, the process is still failing to start. Do I need to create a link in dirsrv.target.wants to somewhere? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] importing old NIS passwd/group maps into Free IPA
On 11/11/2011 05:12 PM, Boris Epstein wrote: > Hello all, > > The question is in the subject. Is there an established reliable way > of doing that? > > Thanks. > > Boris. > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/migrating-from-nis.html This is so far what we have. -- 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] Fedora 16 failing to start dirsrv process
On Mon, 14 Nov 2011, Dan Scott wrote: > Hi, > > I've just upgraded a server from Fedora 15 to 16 and I'm having > problems starting the dirsrv process: > > /var/log/messages > Nov 14 09:38:27 fileserver1 ipactl[1351]: Failed to read data from > Directory Service: Unknown error when retrieving list of services from > LDAP: [Errno 2] No such file or directory > Nov 14 09:38:27 fileserver1 ipactl[1351]: Shutting down > Nov 14 09:38:27 fileserver1 ipactl[1351]: Starting Directory Service > Nov 14 09:38:27 fileserver1 systemd[1]: ipa.service: main process > exited, code=exited, status=1 > Nov 14 09:38:27 fileserver1 systemd[1]: Unit ipa.service entered failed state. > > The /var/log/dirsrv/slapd-EXAMPLE-COM/errors file contains no new > entries since Friday 11th. > > Any ideas how I can get this fixed? How can I find out which 'file or > directory' is missing? Looks like LDAP socket is not yet available at the time we try to contact it. I think this was fixed in Fedora 16 package with this patch: http://git.fedorahosted.org/git/?p=freeipa.git;a=commitdiff;h=5451328bc55fe964c61e7b87959310f9c6748cf8 Could you make sure 'systemctl start dirsrv.target' actually starts slapd for EXAMPLE-COM? If not, please show output of ls -l /etc/systemd/system/dirsrv.target.wants It may be that we would need to make a small upgrade script that re-installs proper systemd instances for dirsrv.target as those are produced during ipa-server-install and cannot be done automatically on upgrade without proper intervention yet. Fedora 15 to Fedora 16 upgrade is a bit complicated due to change from System V to systemd. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fedora 16 failing to start dirsrv process
Hi, I've just upgraded a server from Fedora 15 to 16 and I'm having problems starting the dirsrv process: /var/log/messages Nov 14 09:38:27 fileserver1 ipactl[1351]: Failed to read data from Directory Service: Unknown error when retrieving list of services from LDAP: [Errno 2] No such file or directory Nov 14 09:38:27 fileserver1 ipactl[1351]: Shutting down Nov 14 09:38:27 fileserver1 ipactl[1351]: Starting Directory Service Nov 14 09:38:27 fileserver1 systemd[1]: ipa.service: main process exited, code=exited, status=1 Nov 14 09:38:27 fileserver1 systemd[1]: Unit ipa.service entered failed state. The /var/log/dirsrv/slapd-EXAMPLE-COM/errors file contains no new entries since Friday 11th. Any ideas how I can get this fixed? How can I find out which 'file or directory' is missing? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sssd not updating reverse dns
On Mon, 2011-11-14 at 07:40 -0500, Stephen Gallagher wrote: > On Sun, 2011-11-13 at 19:19 +0100, Sigbjorn Lie wrote: > > On 11/13/2011 02:48 PM, Simo Sorce wrote: > > > On Sat, 2011-11-12 at 15:55 +0100, Sigbjorn Lie wrote: > > >> Hi, > > >> > > >> I notice that when sssd is configured to update DNS, it's only updating > > >> the DNS forward zone, it's not updating the DNS reverse zone. And I > > >> cannot find any option for enabling updating of the reverse dns zone. > > >> > > >> Have I missed something? Or is updating the reverse zone not supported? > > > It is not supported at this time. > > > While we have a way to determine if your host has any right to update > > > the machine A/ name because we can check if the host authenticated > > > using a key of type host/@REALM we have no way to validate that > > > a host has any right to update a PTR record. > > > > > > Allowing a host to change any PTR record in any reverse zone would be > > > very disruptive as a compromised host could change PTR records for > > > important servers. > > > > > Ok, I see the issue. > > > > I notice ISC dhcpd adds a TXT record along with the updated record with > > a string that identifies that host record being "owned" by that dhcpd. > > And it does not attempt to update DNS if it cannot validate the content > > of the TXT record, or there already exists a record without a > > corresponding TXT record. > > > > Perhaps a similar approach could be applied to IPA? Using attributes in > > the LDAP DNS tree instead of TXT records.. ? > > > > SSSD doesn't user LDAP in any way while updating the DNS records. We > actually just use GSS-TSIG to speak directly to the DNS server. We > suggested using XML-RPC communication to the FreeIPA server at one > point, but we decided that it was probably for the best to just stick > with the standardized approach for now. > > The flip side of this is, of course, that we cannot update the PTR > records (due to the security risks that Simo pointed out). So maybe we > should consider putting this back on the table. No, we made some vague plan to have a config option in LDAP and let bind-dyndb-ldap autonomously change the PTR record is the A/ record change was successful and we do control the reverse. This has one downside which is that the same DNS server must be authoritative and manage both direct and reverse maps, but it allows for a simpler client side. 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] sssd not updating reverse dns
On Sun, 2011-11-13 at 19:19 +0100, Sigbjorn Lie wrote: > On 11/13/2011 02:48 PM, Simo Sorce wrote: > > On Sat, 2011-11-12 at 15:55 +0100, Sigbjorn Lie wrote: > >> Hi, > >> > >> I notice that when sssd is configured to update DNS, it's only updating > >> the DNS forward zone, it's not updating the DNS reverse zone. And I > >> cannot find any option for enabling updating of the reverse dns zone. > >> > >> Have I missed something? Or is updating the reverse zone not supported? > > It is not supported at this time. > > While we have a way to determine if your host has any right to update > > the machine A/ name because we can check if the host authenticated > > using a key of type host/@REALM we have no way to validate that > > a host has any right to update a PTR record. > > > > Allowing a host to change any PTR record in any reverse zone would be > > very disruptive as a compromised host could change PTR records for > > important servers. > > > Ok, I see the issue. > > I notice ISC dhcpd adds a TXT record along with the updated record with > a string that identifies that host record being "owned" by that dhcpd. > And it does not attempt to update DNS if it cannot validate the content > of the TXT record, or there already exists a record without a > corresponding TXT record. > > Perhaps a similar approach could be applied to IPA? Using attributes in > the LDAP DNS tree instead of TXT records.. ? > SSSD doesn't user LDAP in any way while updating the DNS records. We actually just use GSS-TSIG to speak directly to the DNS server. We suggested using XML-RPC communication to the FreeIPA server at one point, but we decided that it was probably for the best to just stick with the standardized approach for now. The flip side of this is, of course, that we cannot update the PTR records (due to the security risks that Simo pointed out). So maybe we should consider putting this back on the table. > > We are trying to make sure (patches, configurations) that reverse > > resolution is disabled for kerberos and canonicalization does not use it > > by default as it is unreliable in any case. > Yes, I've noticed. :) Authentication based on forward/reverse lookups > aside, being able to look up reverse IP records does help > troubleshooting. And it becomes almost a requirement for being able to > manage IPv6 networks. > > It would be very nice to see reverse address update implemented in SSSD > at some point. Is there already an open RFE? There is no RFE for this yet. Please feel free to open one at https://fedorahosted.org/sssd signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
