[Freeipa-users] Re: Major Server Failure

[Michael Rainey (Contractor, Code 7320) via FreeIPA-users]

Well... I made a what think is a major oopsie.  I was working my way 
through the guide from the link below.  I was having good success 
exporting the directory database and migrating the data to a failing 
server.  When attempting to load the data I overlooked the file 
ownership and the import failed. I corrected the mistake and 
successfully imported the data.


Now the problem is that the system is missing the dirsrv@. Now 
i can't start the service.

# systemctl status dirsrv
dirsrv-admin.service  dirsrv-snmp.service dirsrv.target


What can be done to bring back the service?


*Michael Rainey*
Network Representative
Naval Research Laboratory, Code 7320
Building 1009, Room C156
Stennis Space Center, MS 39529

On 05/10/2018 03:06 PM, Mark Reynolds via FreeIPA-users wrote:


On 05/10/2018 03:30 PM, Rob Crittenden wrote:

Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:

Sigh... My replication agreements really do seem to be completely
jacked up.  I would have expected the hostname replica agreements and
the hostname csreplica agreements to match.

This is fairly typical. You don't really need a full CA on every
master you just want > 1 CAs in your installation.

Maybe Mark can provide some insight into the replication issues.

replication is not working because the master can not bind to the
consumer to initialize it.  Another option is to do an offline
initialization so that the consumer gets the usercertificate it needs
for incremental replication to work.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-initializing_consumers#Initializing_Consumers-Manual_Consumer_Initialization_Using_the_Command_Line

I think that once we work that out the the other CA master will get
its updated certificate via standard means and things will hopefully
just work at that point.

rob


# ipa-replica-manage list fitch. -v
Directory Manager password:

kodiak.: replica
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (18) Replication error acquiring
replica: Incremental update transient error.  Backing off, will
retry update later. (transient error)
   last update ended: 1970-01-01 00:00:00+00:00
piston.: replica
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (0) Replica acquired successfully:
Incremental update succeeded
   last update ended: 2018-05-10 19:11:56+00:00
tierod.: replica
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (18) Replication error acquiring
replica: Incremental update transient error.  Backing off, will
retry update later. (transient error)
   last update ended: 1970-01-01 00:00:00+00:00
# ipa-csreplica-manage list fitch. -v
Directory Manager password:

voge.
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (0) No replication sessions started
since server startup
   last update ended: 1970-01-01 00:00:00+00:00


*Michael Rainey*
Network Representative
Naval Research Laboratory, Code 7320
Building 1009, Room C156
Stennis Space Center, MS 39529

On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:

Sigh. This is what I get when I type too fast.

No worries.  You're helping me to make some headway on this problem.

This is more of what you are wanting to see, and for me it doesn't
look good.  Does this mean I'll be using the re-initialize option or
some variation?


ipa-csreplica-manage list fitch. -v
Directory Manager password:

voge.
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (0) No replication sessions started
since server startup
   last update ended: 1970-01-01 00:00:00+00:00


*Michael Rainey*
Network Representative
Naval Research Laboratory, Code 7320
Building 1009, Room C156
Stennis Space Center, MS 39529

On 05/10/2018 12:09 PM, Rob Crittenden wrote:

Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:

Use ipa-cacert-manage -v `hostname` to see what the status is.

Is this correct usage for this command?  It throws out debug
messages.

Sigh. This is what I get when I type too fast.

ipa-csreplica-manage ...

rob


ipa-cacert-manage -v 'fitch'
ipa: DEBUG: Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
Usage: ipa-cacert-manage renew [options]
    ipa-cacert-manage install [options] CERTFILE

ipa-cacert-manage: error: unknown command "fitch"
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
169, in execute
     self.validate_options()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py",
line 105, in validate_options
     parser.error("unknown command \"%s\"" % command)
   File "/usr/lib64/python2.7/optparse.py", line 1583, in error
     self.exit(2, "%s: error: 

[Freeipa-users] Re: obtaining initial ticket via keytab

[Simo Sorce via FreeIPA-users]

On Mon, 2018-05-14 at 14:44 -0400, Josh via FreeIPA-users wrote:
> On 05/14/2018 01:29 PM, Alexander Bokovoy wrote:
> > Talking with Simo, we realized that since we are using random salt for
> > all IPA principals, you need to know the salt when creating a keytab
> > entry. You only can retrieve that via KRB5_TRACE for kinit like I did in
> > https://paste.fedoraproject.org/paste/KPt2PbYsdluhAJcVLdQjBg but since
> > salt is random, it may have characters that aren't clean for a shell
> > use, so your scripting mileage may vary. 
> 
> Thanks a lot! That is helpful. However man page for ktutil has no word 
> for salt:
> 
> add_entry
>    add_entry {-key|-password} -p principal -k kvno -e enctype
> 
> and attempt to add -s option results in invalid usage error.
> 
> usage: addent (-key | -password) -p principal -k kvno -e enctype
> 
> $ rpm -qf /usr/bin/ktutil
> krb5-workstation-1.15.1-8.el7.x86_64

I think -s has been added in 1.16 :-(

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: some basic questions about FreeIPA

[Jochen Hein via FreeIPA-users]

Udo Rader via FreeIPA-users 
writes:

> Our current setup looks like this:
...
> #4 DHCP is handled by multiple, distributed ISC DHCP servers,
> configured to pull their configuration from OpenLDAP (network
> definitions, routers, NTP servers, MAC addresses etc.)
...
> Regarding DHCP, all I found were some older documents describing
> intentions to implement it [1], but I'm uncertain if that ever
> happened.

I'm using dnsmasq for DHCP.  My workflow is something like this:

- A host gets added to FreeIPA, its IP address is stored in LDAP for
  IPA's DNS.

- I manually add the MAC address to the server record:
  ipa host-mod  --macaddress=

- A script pulls the hosts from IPA and generates a config fragment for
  dnsmasq.  If there were changes, dnsmasq is reloaded.

Jochen

#!/bin/bash

tmp=/etc/dnsmasq.d/dynamic-hosts.conf.tmp

KRBPRINC='host/.example@example.org'

kinit -k $KRBPRINC

cat > $tmp <> ${tmp}.$$

LC_ALL=C.UTF-8 ipa host-find --all --raw | awk '
/fqdn:/ { ipstr=""; split($2,host,".") }
# for multi-home hosts, description contains the interface-name.
/iface:/ { "getent ahostsv4 " host[1] "-" $2 | getline ipstr; 
split(ipstr, ip, " ");
if ( ip[1] != "" )
printf "dhcp-host=" $3 ",id:*," ip[1] "," host[1] "-" 
$2 ",24h\n"
else
printf "ERROR: no ip for host »%s« and interface 
»%s«.\n", host[1], $2 > "/dev/stderr" }' >> ${tmp}.$$

sort < ${tmp}.$$ > $tmp
rm -f ${tmp}.$$

kdestroy -A

if cmp -s $out $tmp; then
rm -f $tmp ${tmp}.empty
else
if cmp -s ${tmp} ${tmp}.empty; then
rm -f ${tmp} ${tmp}.empty
else
mv $tmp $out
rm -f ${tmp}.empty
systemctl restart dnsmasq.service
fi
fi

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Jonathan Vaughn via FreeIPA-users]

Here's a strace from before it dies. Most of the elapsed time is it waiting
on some futex call it looks like near the end, when it finally "returns"
(from lack of strace output for duration of call I assume it didn't
actually return but SIGSEGV in that call) and strace prints ' = ?' on the
futex it then immediately reports SIGSEGV after. So maybe the problem is
that futex call, which may mean the problem is not directly in 389DS /
FreeIPA itself?



15:13:31.626587 (+ 0.000630) listen(8, 128) = 0 <0.68>
15:13:31.626857 (+ 0.000235) listen(9, 128) = 0 <0.48>
15:13:31.627111 (+ 0.000251) clock_gettime(CLOCK_MONOTONIC,
{tv_sec=1464932, tv_nsec=41120614}) = 0 <0.85>
15:13:31.627457 (+ 0.000356) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=627560772}) = 0 <0.43>
15:13:31.631233 (+ 0.003839) clock_gettime(CLOCK_MONOTONIC,
{tv_sec=1464932, tv_nsec=45286796}) = 0 <0.77>
15:13:31.631720 (+ 0.000427) clock_gettime(CLOCK_MONOTONIC,
{tv_sec=1464932, tv_nsec=45661430}) = 0 <0.42>
15:13:31.631955 (+ 0.000220) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=632049036}) = 0 <0.47>
15:13:31.635669 (+ 0.003785) clock_gettime(CLOCK_MONOTONIC,
{tv_sec=1464932, tv_nsec=49725840}) = 0 <0.000146>
15:13:31.636484 (+ 0.000784) write(16, "a", 1) = 1 <0.000118>
15:13:31.636855 (+ 0.000341) sched_yield() = 0 <0.000252>
15:13:31.637322 (+ 0.000470) futex(0x1cb57a0, FUTEX_WAKE_PRIVATE, 1) =
1 <0.88>
15:13:31.637897 (+ 0.000610) write(16, "a", 1) = 1 <0.000221>
15:13:31.638394 (+ 0.000467) sched_yield() = 0 <0.47>
15:13:31.638619 (+ 0.000202) futex(0x1cb5710, FUTEX_WAKE_PRIVATE, 1) =
1 <0.65>
15:13:31.638908 (+ 0.000298) openat(AT_FDCWD,
"/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid", O_WRONLY|O_CREAT|O_TRUNC,
0666) = 33 <0.000831>
15:13:31.640260 (+ 0.001387) getpid() = 32353 <0.77>
15:13:31.640558 (+ 0.000256) fstat64(33, {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0 <0.000119>
15:13:31.641106 (+ 0.000556) write(33, "32353\n", 6) = 6 <0.000127>
15:13:31.641472 (+ 0.000362) close(33) = 0 <0.000519>
15:13:31.642216 (+ 0.000758)
chmod("/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid", 0644) = 0 <0.000152>
15:13:31.642900 (+ 0.000679) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=643020294}) = 0 <0.56>
15:13:31.643495 (+ 0.000590) write(2, "[14/May/2018:15:13:31.643020294
"..., 134) = 134 <0.002697>
15:13:31.646515 (+ 0.003052) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=646694394}) = 0 <0.75>
15:13:31.646892 (+ 0.000337) write(4, "[14/May/2018:15:13:31.646694394
"..., 134) = 134 <0.000522>
15:13:31.647841 (+ 0.000973) fsync(4) = 0 <0.005967>
15:13:31.654425 (+ 0.006617) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=654598946}) = 0 <0.000253>
15:13:31.655137 (+ 0.000717) write(2, "[14/May/2018:15:13:31.654598946
"..., 136) = 136 <0.002427>
15:13:31.658312 (+ 0.003165) clock_gettime(CLOCK_REALTIME,
{tv_sec=1526328811, tv_nsec=658486117}) = 0 <0.000251>
15:13:31.659032 (+ 0.000682) write(4, "[14/May/2018:15:13:31.658486117
"..., 136) = 136 <0.000346>
15:13:31.659623 (+ 0.000595) fsync(4) = 0 <0.003311>
15:13:31.663230 (+ 0.003642) getpid() = 32353 <0.45>
15:13:31.663732 (+ 0.000454) socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC,
0) = 33 <0.000296>
15:13:31.664760 (+ 0.001048) getsockopt(33, SOL_SOCKET, SO_SNDBUF,
[163840], [4]) = 0 <0.000108>
15:13:31.665141 (+ 0.000386) setsockopt(33, SOL_SOCKET, SO_SNDBUFFORCE,
[8388608], 4) = -1 EPERM (Operation not permitted) <0.51>
15:13:31.665500 (+ 0.000334) setsockopt(33, SOL_SOCKET, SO_SNDBUF,
[8388608], 4) = 0 <0.000229>
15:13:31.665973 (+ 0.000468) sendmsg(33, {msg_name={sa_family=AF_UNIX,
sun_path="/run/systemd/notify"}, msg_namelen=21,
msg_iov=[{iov_base="READY=1\nSTATUS=slapd started: Re"..., iov_len=69}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 69 <0.000600>
15:13:31.667270 (+ 0.001334) close(33) = 0 <0.003140>
15:13:31.677320 (+ 0.010146) futex(0xb31122e8, FUTEX_WAIT, 32357, NULL)
= ?
15:14:27.661809 (+55.984448) +++ killed by SIGSEGV (core dumped) +++

On Mon, May 14, 2018 at 10:27 AM, thierry bordaz  wrote:

> Hi Jonathan,
>
> This is weird as the crashing thread stack looks truncated (did you
> copy/paste all of it ?)
>
> Thread 1 (Thread 0x9e13c280 (LWP 17245)):
> #0  0xb67bbf2e in strlen () at /lib/libc.so.6
> #1  0xb6a06b40 in dosprintf () at /lib/libnspr4.so
> #2  0x in None ()
>
> Did you install 389-ds-base-debuginfo ?
> How did you get that backtrace ? from a core dumped, pstack ? Can you
> attach a debugger before the crash occurs ?
>
> It looks it crashed soon at startup, could it be related to a broken
> dse.ldif. It should exists a dse.ldif.OK, is it possibly to try to start
> with it ?
>
> best regards
> thierry
>
> On 05/12/2018 01:22 AM, Jonathan Vaughn via 

[Freeipa-users] Re: obtaining initial ticket via keytab

[Josh via FreeIPA-users]

On 05/14/2018 01:29 PM, Alexander Bokovoy wrote:

Talking with Simo, we realized that since we are using random salt for
all IPA principals, you need to know the salt when creating a keytab
entry. You only can retrieve that via KRB5_TRACE for kinit like I did in
https://paste.fedoraproject.org/paste/KPt2PbYsdluhAJcVLdQjBg but since
salt is random, it may have characters that aren't clean for a shell
use, so your scripting mileage may vary. 
Thanks a lot! That is helpful. However man page for ktutil has no word 
for salt:


add_entry
  add_entry {-key|-password} -p principal -k kvno -e enctype

and attempt to add -s option results in invalid usage error.

usage: addent (-key | -password) -p principal -k kvno -e enctype

$ rpm -qf /usr/bin/ktutil
krb5-workstation-1.15.1-8.el7.x86_64

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

[Freeipa-users] Re: obtaining initial ticket via keytab

[Alexander Bokovoy via FreeIPA-users]

On ma, 14 touko 2018, Rob Crittenden via FreeIPA-users wrote:

Josh via FreeIPA-users wrote:

On 05/12/2018 01:53 AM, Alexander Bokovoy wrote:

On pe, 11 touko 2018, Josh wrote:

On 05/11/2018 01:19 AM, Alexander Bokovoy wrote:

On to, 10 touko 2018, Josh via FreeIPA-users wrote:

Server certificate has expired and all ipa utilities fail.
Could you please stay on topic and explain if you can why 
ktutil can't be used as described in 
https://kb.iu.edu/d/aumh?

Does ipa makes ktutil not functional?

Can you show output of

kinit admin
kvno admin
klist -ef

I suspect your admin password did change over time so it has a different
kvno value than what you have used in ktutil's addent (-k 1).



I modified a script posted on https://stackoverflow.com/questions/37454308/script-kerberos-ktutil-to-make-keytabs 
to create a simple test case:


#!/bin/bash
user=admin
read -sp "${user}'s pass:" pass
echo
kinit $user
KVNO=$(kvno "$user" | awk '{print $NF}')
ETYPE=$(klist -ef | grep -A 1 krbtgt | tail -1 | awk '{print $NF}')
printf "%b" "addent -password -p $user -k $KVNO -e 
$ETYPE\n$pass\nwrite_kt $user.keytab" | ktutil

printf "%b" "read_kt $user.keytab\nlist\nquit\n" | ktutil
kinit -k -t $user.keytab $user


The result when ran from an IPA host is the same error as before: 
kinit: Preauthentication failed while getting initial credentials 
despite the fact that KVNO numbers match.
Could anyone confirm that admin keytab acquired via ipa_getkeytab is 
working and if yes then what is the difference from above method?


ipa-getkeytab works for me, I don't know why ktutil isn't working but 
we do zero testing using this.

Talking with Simo, we realized that since we are using random salt for
all IPA principals, you need to know the salt when creating a keytab
entry. You only can retrieve that via KRB5_TRACE for kinit like I did in
https://paste.fedoraproject.org/paste/KPt2PbYsdluhAJcVLdQjBg but since
salt is random, it may have characters that aren't clean for a shell
use, so your scripting mileage may vary.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: adding users to other user groups

[Andrew Meyer via FreeIPA-users]

Ok.  I will check this out.
Thank you!

On Monday, May 14, 2018 10:59 AM, Alexander Bokovoy via FreeIPA-users 
 wrote:
 

 On ma, 14 touko 2018, Andrew Meyer via FreeIPA-users wrote:
>Hello,I am trying to add a new user to another group.  This group was
>setup for another user.  When I create the user is seems to do the same
>thing as when I create them on a local system.  I get a User and a
>group for the user as well.  However when I go to add another user to
>that newly created group I can't find it.  If I go to create the group
>with the same name FIPA says its already created.    Any reason its
>doing this?  Am I doing something wrong?
>I am running CentOS 7.4, FreeIPA 4.5.x.
By what you describe you are dealing with user private groups. The
concept of a user private group is that it is automatically managed
for the user -- it has the same GID as that user's UID, you cannot
create a group with the same name manually and so on. It is not supposed
to be used for *other* users.

If you really are willing to use that group for other purposes, you need
to disassociate the group from the original user:

$ ipa help group-detach
Usage: ipa [global-options] group-detach GROUP-NAME [options]

Detach a managed group from a user.
Options:
  -h, --help  show this help message and exit

See RHEL IdM doucmentation.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#user-private-groups

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


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

[Freeipa-users] Re: adding users to other user groups

[Alexander Bokovoy via FreeIPA-users]

On ma, 14 touko 2018, Andrew Meyer via FreeIPA-users wrote:

Hello,I am trying to add a new user to another group.  This group was
setup for another user.  When I create the user is seems to do the same
thing as when I create them on a local system.  I get a User and a
group for the user as well.  However when I go to add another user to
that newly created group I can't find it.  If I go to create the group
with the same name FIPA says its already created.    Any reason its
doing this?  Am I doing something wrong?
I am running CentOS 7.4, FreeIPA 4.5.x.

By what you describe you are dealing with user private groups. The
concept of a user private group is that it is automatically managed
for the user -- it has the same GID as that user's UID, you cannot
create a group with the same name manually and so on. It is not supposed
to be used for *other* users.

If you really are willing to use that group for other purposes, you need
to disassociate the group from the original user:

$ ipa help group-detach
Usage: ipa [global-options] group-detach GROUP-NAME [options]

Detach a managed group from a user.
Options:
 -h, --help  show this help message and exit

See RHEL IdM doucmentation.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#user-private-groups

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] adding users to other user groups

[Andrew Meyer via FreeIPA-users]

Hello,I am trying to add a new user to another group.  This group was setup for 
another user.  When I create the user is seems to do the same thing as when I 
create them on a local system.  I get a User and a group for the user as well.  
However when I go to add another user to that newly created group I can't find 
it.  If I go to create the group with the same name FIPA says its already 
created.   
Any reason its doing this?  Am I doing something wrong?
I am running CentOS 7.4, FreeIPA 4.5.x.
Thank you,
Andrew___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[thierry bordaz via FreeIPA-users]

Hi Jonathan,

This is weird as the crashing thread stack looks truncated (did you 
copy/paste all of it ?)


Thread 1 (Thread 0x9e13c280 (LWP 17245)):
#0  0xb67bbf2e in strlen () at /lib/libc.so.6
#1  0xb6a06b40 in dosprintf () at /lib/libnspr4.so
#2  0x in None ()

Did you install 389-ds-base-debuginfo ?
How did you get that backtrace ? from a core dumped, pstack ? Can you 
attach a debugger before the crash occurs ?


It looks it crashed soon at startup, could it be related to a broken 
dse.ldif. It should exists a dse.ldif.OK, is it possibly to try to start 
with it ?


best regards
thierry

On 05/12/2018 01:22 AM, Jonathan Vaughn via FreeIPA-users wrote:
Not sure if it makes a difference... I was looking into this again and 
realized I had a bunch of messages from gdb telling me to install more 
debuginfo. I've done that now, here it is again freshly run through gdb


GNU gdb (GDB) Fedora 8.0.1-36.fc27
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7hl-redhat-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/ns-slapd...Reading symbols from 
/usr/lib/debug/usr/sbin/ns-slapd-1.3.7.10-1.fc27.arm.debug...done.

done.
...

Thread 1 (Thread 0x9e13c280 (LWP 17245)):
#0  0xb67bbf2e in strlen () at /lib/libc.so.6
#1  0xb6a06b40 in dosprintf () at /lib/libnspr4.so
#2  0x in None ()



On Tue, May 8, 2018 at 7:52 AM, Rob Crittenden
> wrote:

Jonathan Vaughn via FreeIPA-users wrote:

Still trying to figure this out. It looks like slapd is
dying, I thought it was still running for some reason.

slapd is dying to segfault. strace of it happening doesn't
seem to reveal much:


A stack trace would very much help trying to track down the cause.


http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes



rob


18:32:41.543717 (+     0.000801) openat(AT_FDCWD,
"/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 32
18:32:41.544907 (+     0.001195) getpid() = 16014
18:32:41.545269 (+     0.000329) fstat64(32,
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
18:32:41.545799 (+     0.000536) write(32, "16014\n", 6) = 6
18:32:41.546603 (+     0.000818) close(32) = 0
18:32:41.547061 (+     0.000448)
chmod("/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid", 0644) = 0
18:32:41.547741 (+     0.000676)
clock_gettime(CLOCK_REALTIME, {tv_sec=1525735961,
tv_nsec=548030641}) = 0
18:32:41.548324 (+     0.000587) write(2,
"[07/May/2018:18:32:41.548030641 "..., 134) = 134
18:32:41.551096 (+     0.002840)
clock_gettime(CLOCK_REALTIME, {tv_sec=1525735961,
tv_nsec=551287555}) = 0
18:32:41.551568 (+     0.000406) write(4,
"[07/May/2018:18:32:41.551287555 "..., 134) = 134
18:32:41.552360 (+     0.000811) fsync(4) = 0
18:32:41.558499 (+     0.006170)
clock_gettime(CLOCK_REALTIME, {tv_sec=1525735961,
tv_nsec=558678099}) = 0
18:32:41.558901 (+     0.000350) write(2,
"[07/May/2018:18:32:41.558678099 "..., 136) = 136
18:32:41.561537 (+     0.002680)
clock_gettime(CLOCK_REALTIME, {tv_sec=1525735961,
tv_nsec=561718659}) = 0
18:32:41.562357 (+     0.000793) write(4,
"[07/May/2018:18:32:41.561718659 "..., 136) = 136
18:32:41.563293 (+     0.001148) fsync(4) = 0
18:32:41.566928 (+     0.003452) getpid() = 16014
18:32:41.567712 (+     0.000752) socket(AF_UNIX,
SOCK_DGRAM|SOCK_CLOEXEC, 0) = 32
18:32:41.568628 (+     0.000912) getsockopt(32,
SOL_SOCKET, SO_SNDBUF, [163840], [4]) = 0
18:32:41.568972 (+     0.000319) setsockopt(32,
SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM
(Operation not permitted)
18:32:41.569548 (+     0.000589) setsockopt(32,
SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
18:32:41.570064 (+     0.000513) sendmsg(32,

[Freeipa-users] Re: obtaining initial ticket via keytab

[Rob Crittenden via FreeIPA-users]

Josh via FreeIPA-users wrote:

On 05/12/2018 01:53 AM, Alexander Bokovoy wrote:

On pe, 11 touko 2018, Josh wrote:

On 05/11/2018 01:19 AM, Alexander Bokovoy wrote:

On to, 10 touko 2018, Josh via FreeIPA-users wrote:

Server certificate has expired and all ipa utilities fail.
Could you please stay on topic and explain if you can why ktutil 
can't be used as described in https://kb.iu.edu/d/aumh?

Does ipa makes ktutil not functional?

Can you show output of

kinit admin
kvno admin
klist -ef

I suspect your admin password did change over time so it has a different
kvno value than what you have used in ktutil's addent (-k 1).



I modified a script posted on 
https://stackoverflow.com/questions/37454308/script-kerberos-ktutil-to-make-keytabs 
to create a simple test case:


#!/bin/bash
user=admin
read -sp "${user}'s pass:" pass
echo
kinit $user
KVNO=$(kvno "$user" | awk '{print $NF}')
ETYPE=$(klist -ef | grep -A 1 krbtgt | tail -1 | awk '{print $NF}')
printf "%b" "addent -password -p $user -k $KVNO -e 
$ETYPE\n$pass\nwrite_kt $user.keytab" | ktutil

printf "%b" "read_kt $user.keytab\nlist\nquit\n" | ktutil
kinit -k -t $user.keytab $user


The result when ran from an IPA host is the same error as before: kinit: 
Preauthentication failed while getting initial credentials despite the 
fact that KVNO numbers match.
Could anyone confirm that admin keytab acquired via ipa_getkeytab is 
working and if yes then what is the difference from above method?


ipa-getkeytab works for me, I don't know why ktutil isn't working but we 
do zero testing using this.


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

[Freeipa-users] Re: Accessing IPA host data from an enrolled workstation

[Alexander Bokovoy via FreeIPA-users]

On ma, 14 touko 2018, David Harvey wrote:

Thank you, that's a great help.

One follow up question. Is there some way of cajoling ipa host-show into
only displaying specific fields? Or is it better just to use ldapsearch
with a suitable search filter (given both need to use the host or a service
keytab if this is to be run by puppet).

If you only need them, just use ldapsearch. There is no way to control
what fields returned by IPA CLI -- it is a default set or everything
(--all).


The fields I'm interested in (descriptions, platform, OS, Class) are
thankfully available (at least using the host principal).

Good.



Kind regards,

David

On 14 May 2018 at 14:14, Alexander Bokovoy  wrote:


On ti, 27 maalis 2018, David Harvey via FreeIPA-users wrote:


Dear list,

I'm currently tinkering with adding host attributes (As custom attrs, or
for the moment into the description field).  My intention is to then read
these from the host in order to define some local behaviour for scripts or
puppet.

Example - a concept of machine ownership, or device class for local
scripts
or puppet to know about.

The two ways I've thought of so far entail

  - having the CLI tools installed to run IPA commands, or
  - kinit -kt /etc/krb5.keytab followed by ldapsearch to read in the parts
  I'm interested in.

It occurred to me that sssd or some other components I understand less
well
might already be able to trivially read the host data IPA holds, or that
the kinit might not be needed given the machine can already read out
getent
aprts direct from LDAP/IPA values with a non network account in use.

Any ideas or suggestion around this so I don't reinvent the wheel?


While SSSD can be taught to read user-specific attributes by adding them
in the configuration, the same cannot be done for host-specific
attributes. So you are back to those two methods you outline above.

One note is that you'd need to add permissions to be able to read the
attributes we don't explicitly allow for services/host principals. See
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ for
details on how to achieve that. For plugin examples look at my
github.com/abbra/ page for freeipa-* plugin repos.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Accessing IPA host data from an enrolled workstation

[David Harvey via FreeIPA-users]

Thank you, that's a great help.

One follow up question. Is there some way of cajoling ipa host-show into
only displaying specific fields? Or is it better just to use ldapsearch
with a suitable search filter (given both need to use the host or a service
keytab if this is to be run by puppet).
The fields I'm interested in (descriptions, platform, OS, Class) are
thankfully available (at least using the host principal).

Kind regards,

David

On 14 May 2018 at 14:14, Alexander Bokovoy  wrote:

> On ti, 27 maalis 2018, David Harvey via FreeIPA-users wrote:
>
>> Dear list,
>>
>> I'm currently tinkering with adding host attributes (As custom attrs, or
>> for the moment into the description field).  My intention is to then read
>> these from the host in order to define some local behaviour for scripts or
>> puppet.
>>
>> Example - a concept of machine ownership, or device class for local
>> scripts
>> or puppet to know about.
>>
>> The two ways I've thought of so far entail
>>
>>   - having the CLI tools installed to run IPA commands, or
>>   - kinit -kt /etc/krb5.keytab followed by ldapsearch to read in the parts
>>   I'm interested in.
>>
>> It occurred to me that sssd or some other components I understand less
>> well
>> might already be able to trivially read the host data IPA holds, or that
>> the kinit might not be needed given the machine can already read out
>> getent
>> aprts direct from LDAP/IPA values with a non network account in use.
>>
>> Any ideas or suggestion around this so I don't reinvent the wheel?
>>
> While SSSD can be taught to read user-specific attributes by adding them
> in the configuration, the same cannot be done for host-specific
> attributes. So you are back to those two methods you outline above.
>
> One note is that you'd need to add permissions to be able to read the
> attributes we don't explicitly allow for services/host principals. See
> https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ for
> details on how to achieve that. For plugin examples look at my
> github.com/abbra/ page for freeipa-* plugin repos.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Accessing IPA host data from an enrolled workstation

[Alexander Bokovoy via FreeIPA-users]

On ti, 27 maalis 2018, David Harvey via FreeIPA-users wrote:

Dear list,

I'm currently tinkering with adding host attributes (As custom attrs, or
for the moment into the description field).  My intention is to then read
these from the host in order to define some local behaviour for scripts or
puppet.

Example - a concept of machine ownership, or device class for local scripts
or puppet to know about.

The two ways I've thought of so far entail

  - having the CLI tools installed to run IPA commands, or
  - kinit -kt /etc/krb5.keytab followed by ldapsearch to read in the parts
  I'm interested in.

It occurred to me that sssd or some other components I understand less well
might already be able to trivially read the host data IPA holds, or that
the kinit might not be needed given the machine can already read out getent
aprts direct from LDAP/IPA values with a non network account in use.

Any ideas or suggestion around this so I don't reinvent the wheel?

While SSSD can be taught to read user-specific attributes by adding them
in the configuration, the same cannot be done for host-specific
attributes. So you are back to those two methods you outline above.

One note is that you'd need to add permissions to be able to read the
attributes we don't explicitly allow for services/host principals. See 
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ for

details on how to achieve that. For plugin examples look at my
github.com/abbra/ page for freeipa-* plugin repos.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: some basic questions about FreeIPA

[Alexander Bokovoy via FreeIPA-users]

On pe, 11 touko 2018, Udo Rader via FreeIPA-users wrote:

Hi,

I'm currently evaluating a couple of options to migrate our dated
OpenLDAP installation to a more up2date, maintainable and and user
friendly solution.

One of the possibilities I found is of course FreeIPA and I hope this
is the right place to as couple of basic questions, in order to get a
better understanding if FreeIPA can meet our requirements.

Our current setup looks like this:

OpenLDAP used as storage for user, DHCP and DNS information:

#1 users are either regular Unix (Linux, FreeBSD) shell users
#2 or they are users accessing our mail services (dovecot/postfix)
#3 (a low number of) certificates are currently handled by TinyCA

#4 DHCP is handled by multiple, distributed ISC DHCP servers,
configured to pull their configuration from OpenLDAP (network
definitions, routers, NTP servers, MAC addresses etc.)

#5 DNS is handled by multiple, distributed PowerDNS instances, which
again retrieve their DNS data from OpenLDAP

As far as I can understand, FreeIPA can easily handle #1, #2 and #3.

But what about DHCP and DNS? I understand that FreeIPA's backbone is
the 389 DS. I guess migrating our DHCP DIT into 389 is doable, but what
about administration of those entries? Can this be done by FreeIPA?

Regarding DHCP, all I found were some older documents describing
intentions to implement it [1], but I'm uncertain if that ever
happened.

It did not happen, indeed. Most time was spent on two things:
- make other projects to implement features required, mostly around
  single sign-on with GSSAPI for ISC DHCP and similar
- make sure we can design a better DHCP storage DIT and schema, an
  opportunity to refactor actual DHCP schema.

The second part was unfinished.

So yes, you could import DHCP DIT and manage it yourself but FreeIPA
will not help you with that. You can start developing a management
plugin for that too, following my examples att github[1]


Regarding DNS, I am aware that FreeIPA comes with bind, but if
possible, I'd really like to stay with PowerDNS. Is that possible? And
if not, how tightly integrated is bind into FreeIPA? One mandatory
requirement is that we need to have multiple, geographically
distributed nameservers that hold various amounts of DNS data
(currently determined by LDAP filters). I of course understand that
bind is perfectly capable of doing this, but depending on the level of
integration between FreeIPA and bind, I'm not exactly sure how "easy"
this can be done.
You can use an approach taken by OpenSUSE folks: 
https://discourse.nordisch.org/t/fun-with-freeipa-and-a-slightly-more-complex-dns-setup/437


[1] See https://github.com/abbra/freeipa-desktop-profile,
https://github.com/abbra/freeipa-userstatus-plugin and other
freeipa-* plugins there.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: some basic questions about FreeIPA

[dbischof--- via FreeIPA-users]

Udo,

On Fri, 11 May 2018, Udo Rader via FreeIPA-users wrote:


[...] Our current setup looks like this:

OpenLDAP used as storage for user, DHCP and DNS information:

#1 users are either regular Unix (Linux, FreeBSD) shell users
#2 or they are users accessing our mail services (dovecot/postfix)
#3 (a low number of) certificates are currently handled by TinyCA

#4 DHCP is handled by multiple, distributed ISC DHCP servers, configured 
to pull their configuration from OpenLDAP (network definitions, routers, 
NTP servers, MAC addresses etc.)


#5 DNS is handled by multiple, distributed PowerDNS instances, which 
again retrieve their DNS data from OpenLDAP


As far as I can understand, FreeIPA can easily handle #1, #2 and #3.

But what about DHCP and DNS? I understand that FreeIPA's backbone is the 
389 DS. I guess migrating our DHCP DIT into 389 is doable, but what 
about administration of those entries? Can this be done by FreeIPA?


Regarding DHCP, all I found were some older documents describing 
intentions to implement it [1], but I'm uncertain if that ever happened.


Regarding DNS, I am aware that FreeIPA comes with bind, but if possible, 
I'd really like to stay with PowerDNS. Is that possible? And if not, how 
tightly integrated is bind into FreeIPA? One mandatory requirement is 
that we need to have multiple, geographically distributed nameservers 
that hold various amounts of DNS data (currently determined by LDAP 
filters). I of course understand that bind is perfectly capable of doing 
this, but depending on the level of integration between FreeIPA and 
bind, I'm not exactly sure how "easy" this can be done.


our IPA-Installation is completely separated from both our DHCP- and 
DNS-Servers, that are maintained using Netdot [1]. All I needed to do was 
to add a certain set of DNS-entries to our DNS zone files. Those entries 
can be displayed with


---
ipa dns-update-system-records --dry-run
---

[1] https://github.com/cvicente/Netdot


Mit freundlichen Gruessen/With best regards,

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

[Freeipa-users] Re: Accessing IPA host data from an enrolled workstation

[David Harvey via FreeIPA-users]

Hi again,

Just a little nudge to see if anyone has attempted any of the prior
mentioned, or if they may have ideas on how this is best achieved..

Kind regards,

David

On 27 March 2018 at 16:22, David Harvey  wrote:

> Dear list,
>
> I'm currently tinkering with adding host attributes (As custom attrs, or
> for the moment into the description field).  My intention is to then read
> these from the host in order to define some local behaviour for scripts or
> puppet.
>
> Example - a concept of machine ownership, or device class for local
> scripts or puppet to know about.
>
> The two ways I've thought of so far entail
>
>- having the CLI tools installed to run IPA commands, or
>- kinit -kt /etc/krb5.keytab followed by ldapsearch to read in the
>parts I'm interested in.
>
> It occurred to me that sssd or some other components I understand less
> well might already be able to trivially read the host data IPA holds, or
> that the kinit might not be needed given the machine can already read out
> getent aprts direct from LDAP/IPA values with a non network account in use.
>
> Any ideas or suggestion around this so I don't reinvent the wheel?
>
> Kind regards,
>
> David
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] some basic questions about FreeIPA

[Udo Rader via FreeIPA-users]

Hi,

I'm currently evaluating a couple of options to migrate our dated
OpenLDAP installation to a more up2date, maintainable and and user
friendly solution.

One of the possibilities I found is of course FreeIPA and I hope this
is the right place to as couple of basic questions, in order to get a
better understanding if FreeIPA can meet our requirements.

Our current setup looks like this:

OpenLDAP used as storage for user, DHCP and DNS information:

#1 users are either regular Unix (Linux, FreeBSD) shell users
#2 or they are users accessing our mail services (dovecot/postfix)
#3 (a low number of) certificates are currently handled by TinyCA

#4 DHCP is handled by multiple, distributed ISC DHCP servers,
configured to pull their configuration from OpenLDAP (network
definitions, routers, NTP servers, MAC addresses etc.)

#5 DNS is handled by multiple, distributed PowerDNS instances, which
again retrieve their DNS data from OpenLDAP

As far as I can understand, FreeIPA can easily handle #1, #2 and #3.

But what about DHCP and DNS? I understand that FreeIPA's backbone is
the 389 DS. I guess migrating our DHCP DIT into 389 is doable, but what
about administration of those entries? Can this be done by FreeIPA?

Regarding DHCP, all I found were some older documents describing
intentions to implement it [1], but I'm uncertain if that ever
happened.

Regarding DNS, I am aware that FreeIPA comes with bind, but if
possible, I'd really like to stay with PowerDNS. Is that possible? And
if not, how tightly integrated is bind into FreeIPA? One mandatory
requirement is that we need to have multiple, geographically
distributed nameservers that hold various amounts of DNS data
(currently determined by LDAP filters). I of course understand that
bind is perfectly capable of doing this, but depending on the level of
integration between FreeIPA and bind, I'm not exactly sure how "easy"
this can be done.

Thanks in advance

Udo

[1] https://pagure.io/freeipa/issue/939

-- 
Udo Rader, GF/CEO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

signature.asc
Description: This is a digitally signed message part
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] obtaining initial ticket via keytab

[Josh via FreeIPA-users]

Greetings,

I am trying to follow steps at https://kb.iu.edu/d/aumh to create 
freeipa admin keytab to use in some scripts but getting an error


kinit: Preauthentication failed while getting initial credentials

Does anyone know what I am missing here?

Thanks,
Josh.

$ ktutil
ktutil:  addent -password -p ad...@example.org -k 1 -e aes256-cts
Password for ad...@example.org:
ktutil:  wkt /tmp/admin.kt
ktutil:  quit
$ klist -k /tmp/admin.kt
Keytab name: FILE:/tmp/admin.kt
KVNO Principal
 
--

   1 ad...@example.org
$ klist -k /tmp/admin.kt -e
Keytab name: FILE:/tmp/admin.kt
KVNO Principal
 
--

   1 ad...@example.org (aes256-cts-hmac-sha1-96)
$ kinit -k -t /tmp/admin.kt ad...@example.org
kinit: Preauthentication failed while getting initial credentials
$ kinit admin
Password for ad...@example.org:
$ klist -e
Ticket cache: KEYRING:persistent:1000:1000
Default principal: ad...@example.org

Valid starting   Expires  Service principal
05/09/2018 23:08:46  05/10/2018 23:08:43 krbtgt/example@example.org
    Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
$
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Server Uninstall Fail

[Florence Blanc-Renaud via FreeIPA-users]

On 05/09/2018 12:44 AM, Ross Infinger via FreeIPA-users wrote:


After a failed ipa-replica-install, I try to uninstall with 
ipa-server-install --uninstall.  However the uninstall is failing with 
the following:


[root@ipa-nyc-pci01 ~]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and 
configuration!
It is highly recommended to take a backup of existing data and 
configuration using ipa-backup utility before proceeding.


Are you sure you want to continue with the uninstall procedure? [no]: yes
ipa.ipapython.install.cli.uninstall_tool(CompatServerMasterInstall): 
ERROR    Server removal aborted:


Replication topology in suffix 'domain' is disconnected:
Topology does not allow server ipa-nyc-pci02.pci.example.com to 
replicate with servers:

     ipa-nyc-pci01.pci.example.com
Topology does not allow server pci-mgmt-ipa01.pci.example.com to 
replicate with servers:

     ipa-nyc-pci01.pci.example.com
Topology does not allow server pci-mgmt-ipa02.pci.example.com to 
replicate with servers:

     ipa-nyc-pci01.pci.example.com.
ipa.ipapython.install.cli.uninstall_tool(CompatServerMasterInstall): 
ERROR    The ipa-server-install command failed. See 
/var/log/ipaserver-uninstall.log for more information



Is there a way to manually clean up the failed install?



Hi,

The error means that some servers would be disconnected from the 
replication topology if you uninstall this one. You can graphically 
check your topology in the GUI:

https:///ipa/ui/#/p/topology-graph
and make sure that the removal of ipa-nyc-pci01 would not produce 2 
separate topologies.


Maybe the problematic servers are only left-overs, in this case you can 
try to run:

$ ipa-server-install --uninstall --ignore-topology-disconnect
to force the removal.

HTH,
Flo


___
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