[Freeipa-users] Re: Certmonger managed certificate signed by sub-ca

2019-09-12 Thread Fraser Tweedale via FreeIPA-users 
On Thu, Sep 12, 2019 at 02:10:22PM -0400, Ben Rawson via FreeIPA-users wrote:
> Thanks for the quick response Fraser. I did some more digging based on your
> suggestions, and I think I have a pretty good handle on whats going on.
> 
> We actually have 3 ipa servers, with ipa01 being the CA master. After I
> created the sub-CA, its keys were added to the /etc/pki/pki-tomcat/alias
> database on ipa01, but not ipa02 or ipa03.
> 
> The ipa client on our host was pointing directly to ipa02, and since the CA
> wasn't in the database it was throwing the error in my original post. By
> changing /etc/ipa/default.conf to point at ipa01 (and changing the
> certificate policy,) I was able to get certmonger to issue the cert I
> wanted.
> 
> So the question now is: Shouldn't the pki-tomcat/aliases database get
> automatically replicated from the master to the replicas? What
> configuration is responsible for doing this, and why might it not be
> working?
> 
Yes, sub-CA keys should be replicated automatically.  Something is
not working.

Have a look in the /etc/pki/pki-tomcat/ca/debug log on ipa02 (search
backwards from end for string KeyRetriever and see what's nearby).
If you want to see fresh results, restart Dogtag (systemctl restart
pki-tomcatd@pki-tomcat) because failed key retrieval retries with
exponential backoff.

Also check /var/log/httpd/error_log on ipa-01 to see if there's any
indication why the key retrieval requests failed.

'systemctl restart ipa-custodia' on ipa-01.  Sometimes I have seen
custodia get into a funk and a restart resolves it.

Cheers,
Fraser

> Thanks again for your help,
> Ben
> 
> On Thu, Sep 5, 2019 at 9:22 PM Fraser Tweedale  wrote:
> 
> > On Thu, Sep 05, 2019 at 09:07:48PM -, Ben Rawson via FreeIPA-users
> > wrote:
> > > I'm having some trouble getting sub-ca signed certificates issued and
> > managed by certmonger. The implementation here [
> > https://www.freeipa.org/page/V4/Sub-CAs] describes how that should work.
> > I see that the -X option can be passed to ipa-getcert to specify the
> > issuer, but every time I create a request with -X specified I get an error.
> > >
> > > Steps to reproduce:
> > > 1. Create a new CA named "Test" through the FreeIPA web UI.
> > >
> > > 2. Run the following on a host enrolled in freeIPA:
> > > ipa-getcert request -k /root/test.key -f /root/test.crt -I "testrequest"
> > -X "Test"
> > >
> > > 3. Run ipa-getcert list and receive the an error message:
> > > Request ID 'test':
> > >   status: CA_REJECTED
> > >   ca-error: Server at https://ipa02.yyy.com/ipa/xml failed request,
> > will retry: 4035 (RPC failed at server.  Request failed with status 500:
> > Non-2xx response from CA REST API: 500. ).
> > >   stuck: yes
> > >   key pair storage: type=FILE,location='/root/test.key'
> > >   certificate: type=FILE,location='/root/test.crt'
> > >   CA: IPA
> > >   issuer:
> > >   subject:
> > >   expires: unknown
> > >   pre-save command:
> > >   post-save command:
> > >   track: yes
> > >   auto-renew: yes
> > >
> > > Running FreeIPA 4.6.4
> > >
> > Hi Ben,
> >
> > Have a look at the Dogtag debug log under
> > /var/log/pki/pki-tomcat/ca/, and also the system journal, on host
> > ipa02.yyy.com.  You should see something related to the error above.
> >
> > What is your topology like?  Do you have multiple CA replicas?  Are
> > the sub-CA signing keys present on ipa02, in the Dogtag NSSDB?
> >
> >   # certutil -d /etc/pki/pki-tomcat/alias -L
> >
> > Cheers,
> > Fraser
> >
> 
> 
> -- 
> *Ben Rawson *
> DevOps Engineer
> 614-304-1429
> 
> 
> 99 E. Main Street
> Columbus, OH 43215
> oliveai.com
> Meet Olive, Your Newest Employee 

> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-kra-install fails: Failed to update number range.

2019-09-12 Thread Fraser Tweedale via FreeIPA-users 
On Thu, Sep 12, 2019 at 03:33:26PM -, Dmitry Perets via FreeIPA-users wrote:
> Hi,
> 
> I've created a new IPA replica. 
> ipa-replica-install has completed successfully.
> ipa-ca-install has completed successfully as well.
> However, ipa-kra-install fails.
> 
> In the terminal the fails right here:
> 
> Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes
>   [1/11]: creating ACIs for admin
>   [2/11]: creating installation admin user
>   [3/11]: configuring KRA instance
> Failed to configure KRA instance: Command '/usr/sbin/pkispawn -s KRA -f 
> /tmp/tmp0w3vD5' returned non-zero exit status 1
> See the installation logs and the following files/directories for more 
> information:
>   /var/log/pki/pki-tomcat
>   [error] RuntimeError: KRA configuration failed.
> 
> This is in /var/log/pki/pki-tomcat/kra/debug:
> 
> [12/Sep/2019:15:58:34][http-bio-8443-exec-1]: === Subsystem Configuration ===
> [12/Sep/2019:15:58:34][http-bio-8443-exec-1]: SystemConfigService: validate 
> clone URI: https://t-idm-nbg2-1.poc.customer.de:443
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: SystemConfigService: get 
> configuration entries from master
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange start 
> host=t-idm-nbg2-1.poc.customer.de adminPort=443 eePort=443
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange content: 
> {xmlOutput=[true], sessionID=[5319570421915120898], type=[request]}
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: ConfigurationUtils: POST 
> https://t-idm-nbg2-1.poc.customer.de:443/kra/admin/kra/updateNumberRange
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: Server certificate:
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]:  - subject: 
> CN=t-idm-nbg2-1.poc.customer.de,O=poc.customer.de
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]:  - issuer: CN=Certificate 
> Authority,O=poc.customer.de
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: content from admin interface 
> = standalone="no"?>1Error: Failed to 
> update number range.
> [12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange(): status=1
> java.io.IOException: Error: Failed to update number range.
> 
> I must note that in this environment there were a lot of redeployments of IPA 
> servers, replicating from one another, deleting the original masters etc.
> And right now I have about 10 IPA servers running, out of them 2 with working 
> KRA (this was supposed to be the 3rd one).
> I found a similar issue with an explanation how the number ranges can get 
> depleted, but I am not sure how I can manually resolve this (without killing 
> the entire environment of course):
> https://pagure.io/freeipa/issue/7654
> 
> Could you guide me in the right direction please?
> 
> ipa-server 4.6.4...
> 
It may be an instance of:
https://bugzilla.redhat.com/show_bug.cgi?id=1748766

Can you please provide the kra/CS.cfg and KRA debug log from
t-idm-nbg2-1.poc.customer.de.  That will help confirm if it is the
above issue.

What operating system and Dogtag package versions are you using?

Thanks,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] how do you update certs for kinit -n?

2019-09-12 Thread Charles Hedrick via FreeIPA-users 
Recent versions of freeipa support kinit -n. However we need a file that has 
certificates from all the servers.

We have three servers. Their certificates renew themselves automatically a few 
hours before expiration. But then we need to concatenate all of them and put 
them on all clients. 

It should be part of the ipa client, or may sssd to retrieve the updated certs. 

We depend upon kinit -n as part of the script for doing kinit for users for 
one-time passwords. I had written a hack that uses a random user with no 
abilities. Until we ca find a way to distribute certs whenever they change I’m 
going to return to the hack rather than kinit -n.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certmonger managed certificate signed by sub-ca

2019-09-12 Thread Ben Rawson via FreeIPA-users 
Thanks for the quick response Fraser. I did some more digging based on your
suggestions, and I think I have a pretty good handle on whats going on.

We actually have 3 ipa servers, with ipa01 being the CA master. After I
created the sub-CA, its keys were added to the /etc/pki/pki-tomcat/alias
database on ipa01, but not ipa02 or ipa03.

The ipa client on our host was pointing directly to ipa02, and since the CA
wasn't in the database it was throwing the error in my original post. By
changing /etc/ipa/default.conf to point at ipa01 (and changing the
certificate policy,) I was able to get certmonger to issue the cert I
wanted.

So the question now is: Shouldn't the pki-tomcat/aliases database get
automatically replicated from the master to the replicas? What
configuration is responsible for doing this, and why might it not be
working?

Thanks again for your help,
Ben

On Thu, Sep 5, 2019 at 9:22 PM Fraser Tweedale  wrote:

> On Thu, Sep 05, 2019 at 09:07:48PM -, Ben Rawson via FreeIPA-users
> wrote:
> > I'm having some trouble getting sub-ca signed certificates issued and
> managed by certmonger. The implementation here [
> https://www.freeipa.org/page/V4/Sub-CAs] describes how that should work.
> I see that the -X option can be passed to ipa-getcert to specify the
> issuer, but every time I create a request with -X specified I get an error.
> >
> > Steps to reproduce:
> > 1. Create a new CA named "Test" through the FreeIPA web UI.
> >
> > 2. Run the following on a host enrolled in freeIPA:
> > ipa-getcert request -k /root/test.key -f /root/test.crt -I "testrequest"
> -X "Test"
> >
> > 3. Run ipa-getcert list and receive the an error message:
> > Request ID 'test':
> >   status: CA_REJECTED
> >   ca-error: Server at https://ipa02.yyy.com/ipa/xml failed request,
> will retry: 4035 (RPC failed at server.  Request failed with status 500:
> Non-2xx response from CA REST API: 500. ).
> >   stuck: yes
> >   key pair storage: type=FILE,location='/root/test.key'
> >   certificate: type=FILE,location='/root/test.crt'
> >   CA: IPA
> >   issuer:
> >   subject:
> >   expires: unknown
> >   pre-save command:
> >   post-save command:
> >   track: yes
> >   auto-renew: yes
> >
> > Running FreeIPA 4.6.4
> >
> Hi Ben,
>
> Have a look at the Dogtag debug log under
> /var/log/pki/pki-tomcat/ca/, and also the system journal, on host
> ipa02.yyy.com.  You should see something related to the error above.
>
> What is your topology like?  Do you have multiple CA replicas?  Are
> the sub-CA signing keys present on ipa02, in the Dogtag NSSDB?
>
>   # certutil -d /etc/pki/pki-tomcat/alias -L
>
> Cheers,
> Fraser
>


-- 
*Ben Rawson *
DevOps Engineer
614-304-1429


99 E. Main Street
Columbus, OH 43215
oliveai.com
Meet Olive, Your Newest Employee 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] ipa-kra-install fails: Failed to update number range.

2019-09-12 Thread Dmitry Perets via FreeIPA-users 
Hi,

I've created a new IPA replica. 
ipa-replica-install has completed successfully.
ipa-ca-install has completed successfully as well.
However, ipa-kra-install fails.

In the terminal the fails right here:

Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes
  [1/11]: creating ACIs for admin
  [2/11]: creating installation admin user
  [3/11]: configuring KRA instance
Failed to configure KRA instance: Command '/usr/sbin/pkispawn -s KRA -f 
/tmp/tmp0w3vD5' returned non-zero exit status 1
See the installation logs and the following files/directories for more 
information:
  /var/log/pki/pki-tomcat
  [error] RuntimeError: KRA configuration failed.

This is in /var/log/pki/pki-tomcat/kra/debug:

[12/Sep/2019:15:58:34][http-bio-8443-exec-1]: === Subsystem Configuration ===
[12/Sep/2019:15:58:34][http-bio-8443-exec-1]: SystemConfigService: validate 
clone URI: https://t-idm-nbg2-1.poc.customer.de:443
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: SystemConfigService: get 
configuration entries from master
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange start 
host=t-idm-nbg2-1.poc.customer.de adminPort=443 eePort=443
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange content: 
{xmlOutput=[true], sessionID=[5319570421915120898], type=[request]}
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: ConfigurationUtils: POST 
https://t-idm-nbg2-1.poc.customer.de:443/kra/admin/kra/updateNumberRange
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: Server certificate:
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]:  - subject: 
CN=t-idm-nbg2-1.poc.customer.de,O=poc.customer.de
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]:  - issuer: CN=Certificate 
Authority,O=poc.customer.de
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: content from admin interface 
=1Error: Failed to update 
number range.
[12/Sep/2019:15:58:35][http-bio-8443-exec-1]: updateNumberRange(): status=1
java.io.IOException: Error: Failed to update number range.

I must note that in this environment there were a lot of redeployments of IPA 
servers, replicating from one another, deleting the original masters etc.
And right now I have about 10 IPA servers running, out of them 2 with working 
KRA (this was supposed to be the 3rd one).
I found a similar issue with an explanation how the number ranges can get 
depleted, but I am not sure how I can manually resolve this (without killing 
the entire environment of course):
https://pagure.io/freeipa/issue/7654

Could you guide me in the right direction please?

ipa-server 4.6.4...

---
Regards,
Dmitry Perets
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: services disabled by default on replicas ?

2019-09-12 Thread Florence Blanc-Renaud via FreeIPA-users 

On 9/11/19 10:53 PM, danielle lampert wrote:


When creating the file manually and running the command, this seems to 
work. Later I have other problems : when stopping the main server and 
running only a replica and a client, the client cannot add any user. 
Restarting the main server, everything goes back working, this means my 
lab is not resilient. I'm almost sure to have followed the documentation ()


Here's the error message

# ipa user-add jdalton --first=Joe --last=Dalton
ipa: ERROR: Operations error: Allocation of a new value for range 
cn=posix ids,cn=distributed numeric assignment 
plugin,cn=plugins,cn=config failed! Unable to proceed.


I don't know if this is related to this version (4.5.0-20) or if I need 
to look further what's wrong.




Hi,

this is a known issue already tracked by ticket 5070 [1]
The workaround is the following:
when the first master is still up and running, run ipa user-add on the 
replica. This operation will trigger the allocation of a range on the 
replica. Any subsequent user-add will succeed even if the master is stopped.


HTH,
flo

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




Le mar. 10 sept. 2019 à 21:07, Rob Crittenden > a écrit :


danielle lampert wrote:
 >
 > There's no such file as /usr/lib/tmpfiles.d/ipa.conf
 >
 > # ls -l /usr/lib/tmpfiles.d/ipa.conf
 > ls: cannot access /usr/lib/tmpfiles.d/ipa.conf: No such file or
directory
 >
 > I only find this one
 >
 > # cat /usr/share/ipa/ipa.conf.tmpfiles
 > d /var/run/ipa 0711 root root
 > d /var/run/ipa/ccaches 0770 ipaapi ipaapi
 >
 > I re-installed my VMs more than 20 times, the replica never works
after
 > reboot with the version I'm using.

So create the file using those values and run the systemd command...

rob

 >
 >
 >
 > Le mar. 10 sept. 2019 à 16:48, Rob Crittenden
mailto:rcrit...@redhat.com>
 > >> a écrit :
 >
 >     danielle lampert wrote:
 >     >
 >     > Hello,
 >     >
 >     >> Assuming you have:
 >     >
 >     >> # cat /usr/lib/tmpfiles.d/ipa.conf
 >     >
 >     > I don't have this file, it's not created during the replica
install.
 >     > This log ipareplica-install.log shows :
 >     >
 >     > 2019-09-10T06:43:40Z DEBUG Backing up system configuration file
 >     > '/etc/httpd/conf.d/ipa.conf'
 >     > 2019-09-10T06:43:40Z DEBUG   -> Not backing up -
 >     > '/etc/httpd/conf.d/ipa.conf' doesn't exist
 >     > 2019-09-10T06:43:40Z DEBUG Backing up system configuration file
 >     > '/etc/httpd/conf.d/ipa-rewrite.conf'
 >     > 2019-09-10T06:43:40Z DEBUG   -> Not backing up -
 >     > '/etc/httpd/conf.d/ipa-rewrite.conf' doesn't exist
 >
 >     Ok, those are unrelated.
 >
 >     /usr/lib/tmpfiles.d/ipa.conf should contain:
 >
 >     d /var/run/ipa 0711 root root
 >     d /var/run/ipa/ccaches 0770 ipaapi ipaapi
 >
 >     then run: systemd-tmpfiles --create ipa.conf
 >
 >     rob
 >
 >     >
 >     >
 >     >
 >     > Le ven. 6 sept. 2019 à 19:36, Rob Crittenden
mailto:rcrit...@redhat.com>
 >     >
 >     > 
     >
 >     >     danielle lampert via FreeIPA-users wrote:
 >     >     >
 >     >     > I think I'm just facing Bug 1469246 -  Replica
install fails to
 >     >     > configure IPA-specific temporary files/directories
 >     >     > (https://bugzilla.redhat.com/show_bug.cgi?id=1469246)
 >     >     >
 >     >     > The bug doesn't provide any solution other than
upgrading.
 >     >     > Thanks for your help anyway.
 >     >
 >     >     Assuming you have:
 >     >
 >     >     # cat /usr/lib/tmpfiles.d/ipa.conf
 >     >     d /run/ipa 0711 root root
 >     >     d /run/ipa/ccaches 0770 ipaapi ipaapi
 >     >
 >     >     run
 >     >
 >     >     # systemd-tmpfiles --create ipa.conf
 >     >
 >     >     rob
 >     >
 >     >     >
 >     >     >
 >     >     >
 >     >     >
 >     >     >
 >     >     > Le mer. 4 sept. 2019 à 23:43, danielle lampert
 >     >     > mailto:danielle55.lamp...@gmail.com>
 >     >
 >     >     
 >     >>
 >     >     
 >     

[Freeipa-users] Re: Resilience when accessing CA

2019-09-12 Thread Alexander Bokovoy via FreeIPA-users 

On ke, 11 syys 2019, Dmitry Perets via FreeIPA-users wrote:

Hi,

In several scenarios when CA must be accessed, I face issues with the algorithm 
to select IPA server running CA.
Wanted to check if there is an easy solution in place that I am missing...

For example, if I run "ipa vault-retrieve" on IPA server that doesn't run 
CA/KRA, it will forward the request to another IPA server.
But how will it choose one?
From my tests, looks like the algorithm is:
- If "ca_host" is defined in /etc/ipa/default.conf, use that IPA server
- If it's not defined, fallback to LDAP lookup - query 
"cn=masters,cn=ipa,cn=etc," for servers that have KRA and... choose 
the first result.
So the problem is that neither of these two methods is redundant. If the chosen 
IPA server is down, it just fails, it doesn't try the others.
Is there any solution for this?

I thought it was specific to Vault access, but I discovered the same thing when I simply 
do "ipa host-disable" for some host.
Seems that also in this case there is a need to access CA, so the IPA server 
applies the same algorithm as above - so it looks.
And again, no redundancy. If it cannot reach the chosen IPA server, it won't 
try any other.

Can you confirm that the algorighm is as described above?
Or am I missing anything?


I think the latter should be fixed with https://pagure.io/freeipa/issue/7475 
which is in RHEL 7.7.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Resilience when accessing CA

2019-09-12 Thread Dmitry Perets via FreeIPA-users 
OK, I was probably a bit inaccurate about the algorithm with LDAP lookup. 
I had an impression that IPA always picks the first value, but it looks like it 
does have some randomization, but somehow the first entries are chosen more 
often. I had to run "ipa vault-retrieve" 5-8 times until it finally chose the 
right IPA server. 

While this randomization is better than no randomization at all, still I 
believe that's a suboptimal behavior... When a chosen IPA server fails, it must 
try another one immediately, instead of failing... I think the role model here 
is how IPA discovers servers via SRV records or how krb5 discovers KDCs - there 
is a way to specify preference, but at the same time there is automatic 
resilience...

Then again, maybe I got this all totally wrong...=)

---
Regards,
Dmitry Perets
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org