• Category Archives Red Hat
  • Unix » Linux » Red Hat » Satellite
  • RHEL Satellite 6 Installation & Configuration HOW-TO Part 1

    In the following Blog posts I will post tutorials on how to install and configure RHEL Satellite with all the bells and whistles possible. It will include detailed instructions on setting up each component and how to proceed from there.

    This post assumes a fully functional Red Hat Identity Management stack is present in the current network. The RHEL iDM solution will be used for all linux clients deployed with Satellite. This includes DNS, NTP, users, groups, RBAC and HBAC capabilities. RHEL Satellite will manage pxeboot, dhcp, tftp making this a complete environment for a Linux client domain.

    This first post will be about the machine itself, how to set it up and what to do before starting this Tutorial.

    First up, the machine hardware:

    Minimum requirements:

    • 2 CPU
    • 12 Gigabyte RAM
    • 4 Gigabyte SWAP
    • 64 bit CPU architecture.

    Recommended requirements:

    • 4 CPU
    • 16+ Gigabyte RAM
    • 8+ Gigabyte SWAP
    • 64 bit CPU architecture.

    Continue reading  Post ID 188


  • TheForeman & Openstack

    Quick note to boast about success!

    Although my business isn’t all that big, I did find enough cash to finally start building up Oliekoets datacenter to a full-fledged private cloud.

    Considering I have no wish yet to pay licensing fee’s of any kind, I Implemented it all with open-source freely available software.

    CentOS , Foreman, Katello & Openstack.

    Thanks all! you guys rock. Time to start building my virtual machines.

     

    openstack-foreman


  • RHEL Satellite access

    Today I am going to talk about (remote) access with satellite.

    Apparently, there are a few things that you must know in order to get stuff working correctly.

    First of all: Red Hat Identity Manager <-> Satellite coupling for user accounts.
    When you create the coupling as an external LDAP source in satellite, by default users get put in the anonymous group with very little rights within satellite. Luckily you can also provide a “group” DN for Identity servers which can then be used to assign groups in satellite.


     

    So create a user group (for instance : Admins) in the satellite user interface. Then in the third (external group) tab , assign a coupling between a redhat identity manager (IDM) group and the local admin group. The source however, must be set to “External” instead of your identity server, I am not sure if this is a bug or works as designed. Now, when users login who have the correct LDAP group, will automaticly be added to the new Admins group on satellite. Now you can assign rights (or even check the full admin checkbox) to the Admin usergroup and the remote access is done.


    Now a short paragraph about local webinterface access as the default admin account:

    When satellite needs reconfiguring, or reinstalling, Red Hat notes that the admin password gets reset to a default password and you will simply have to change it again. This is not entirely true. You can put the password of the default admin user in /etc/katello-installer/answers.katello-installer.yaml, but doing so is a security risk according to some people. I am noting that if you have root-access , the security risk of this file is negligant, because you can simply run katello-installer without any arguments and it will printout the admin password on the console after a succesful completion.

    – Mark.

     


  • Firewall rules incomplete when using Autodiscovery with RHEL Satellite 6.1

    There are some things not yet in the RedHat manual concerning implementing discovered hosts provisioning through use of the discovery image in Red Hat Satellite Server.

    First of all, the FDI is also running a very limited foreman-proxy server, so to get full functionality you also need to open port 8443 on the subnet where clients are provisioned in the firewalls. Failure to do so will prevent a discovered client to reboot as instructed by satellite and you will have to push the button by hand.

    So if your server runs on 10.0.0.1 and is provisioning for clients on subnet 10.2.0.0/24 with a firewall in between, you need to “allow” traffic from 10.0.0.1 any port , to 10.2.0.0/24 destination port 8443/TCP , as well.

    Also not widely documented yet, you can enable SSH login on the discovery image with 2 kernel-boot options , add them as usual in the satellite global PXEboot file.

    fdi.ssh=1 and fdi.rootpw=welcome  , which enables ssh and sets the root password to welcome.

    – Mark.