I had a handful of machines enrolled in a demo cluster. About half of them got shut down, and now I can’t SSH into them via Kerberos tickets. Here is my debugging notebook.
Troubleshooting a FreeIPA install:
Reply
Category Archives: Sysadmin
firewall-d for FreeIPA
First hack at a script to open the ports needed by FreeIPA. On Fedora 18, running Firewall D, I ran the below script. Comments and corrections welcome.
IPTables rules for FreeIPA
I end up editing this so much, figure I’d post it here for all to use. This is the standard IPtables config file augmented with those rules required to let through the protocols supported by FreeIPA
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT #TCP ports for FreeIPA -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT #UDP ports for FreeIPA -A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
Openstack Keystone in HTTPD
After calling for Keystone to migrate to HTTPD, several people asked me if I would show how this can be done. Here are the steps.
Client Certificates with mod_nss
Once server side certificates have been set up, setting up client side certificates requires some additional configuration, especially if you want to use them as the source of identity in your applications.
Setting up SSL with NSS is easier than you think
At least, it is on Fedora 16
sudo yum install mod_nss
/etc/httpd/alias/ is populated already with ca and server cert self signed
/etc/httpd/conf.d/nss.conf already exists
change 8443 to 443 in two places
--- /etc/httpd/conf.d/nss.conf.orig 2012-03-29 12:59:06.319470425 -0400 +++ /etc/httpd/conf.d/nss.conf 2012-03-29 12:19:38.862721465 -0400 @@ -17,7 +17,7 @@ # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two # Listen directives: "Listen [::]:8443" and "Listen 0.0.0.0:443" # -Listen 8443 +Listen 443 ## ## SSL Global Context @@ -81,7 +81,7 @@ ## SSL Virtual Host Context ## -+ # General setup for the virtual host #DocumentRoot "/etc/httpd/htdocs"
Make sure your firewall is open on the HTTPS port. Add the following line in /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
before the statement
-A INPUT -j REJECT --reject-with icmp-host-prohibited
and restart the services
sudo systemctl restart iptables.service sudo systemctl restart httpd.service
The documentation provides a lot more detail. Almost all of these steps are performed by the RPM install on F16 and later.
Shared Nothing Diskless Boot
It is possible to run a computer with no persistent storage for its root file system other than a single image downloaded an held in RAM. The computer does not needs a local disk. The computer also does not need a SAN or NAS device for the Root File system.
There are numerous uses for this style of booting. A short list:
- Debugging the installation processes of software packages
- Running computationally intensive tasks on a large array of nodes
- Inventorying the hardware on new servers
- Deploying a light management framework for virtualization hypervisors
DNS Managers in FreeIPA
The Domain Name System (DNS) is an essential part of systems management. If you need to manage multiple physical hosts you’d really benefit by a degree of control of some subset of DNS. With Virtual machines, the sheer number of hosts created demand a responsive DNS. Kerberos, X509 and other security mechanisms require a proper DNS configuration. Yet, for many organizations, DNS is locked down by IT to a very static set of records. Earlier articles discussed User Groups, Host Groups, and Netgroups. The final installment in this series discsusses how to delegate DNS Zone management in FreeIPA.
Netgroup Managers in FreeIPA
The last two articles described how to delegate management of user groups and host groups. The other way to manage both hosts and users in FreeIPA is with Netgroups. Although Netgroups are a concept from NIS, FreeIPA takes them to the next level, and makes them into containers capable of managing both users and groups. This article shows how to delegate the control of a netgroup to a specified user.
Hostgroup Managers in FreeIPA
Last article I discussed delegating the authority to manage group membership using FreeIPA. A related topic delegating the ability to manage groups of hosts. There are two different collections for managing hosts: host groups, and netgroups. The approach to delegating authority for managing each of these is similar, but with important differences. First up: hostgroups.
To create a hostgroup for Beowulf hosts: