her-doy…

It just hit me that I can change up the reg questions, save the xz file with a different name, and point FOG_PXE_BOOT_IMAGE[_32] to the new file in the settings. Another thread created for not thinking well…

@george1421 said in Post Registration Questions and Functions:

a custom plugin and hooked into the registration event.

Very interesting suggestion! I like it and will attempt some research on it!

Is there something unique about the OU that can be calculated at deployment time? For example all computers deployed at IP subnet of 192.168.112.x go to ou “ou=madrid,dc=company,dc=com”. FOG has a way to execute custom bash scripts post image deployment but pre first windows boot.

Unfortunately, no. Most all computers are imaged in a central location, and then taken to their destination. But thank you for the suggestion, though. Also, computers might have already been imaged (via vendor), and just need registration; so post image deployment won’t work in all cases.

I didn’t see anything, so the answer is probably “No,” or I didn’t know how to word my search query, but I’ll ask it anyways.

Is there any way to have the questions that are asked during Full Host Inventory and Registration have any custom questions appended that won’t be overwritten anytime we update the trunk? The same goes for any scripts as well.

My goals behind asking this question are:

• Pass the MAC address through to PacketFence for auto-approval.
• Depending on the answer to the Active Directory question, if yes, then ask what OU the unit should be in.

I’ve the code already written in our .32 version of Fog or about 2 years or so, so I’m not worried about that. It may take some tweaking, but that’s fine. I just don’t want to modify a 64-bit init.xz and a 32-bit init.xz separately, only to have them both “updated” at next “git pull” & “./installsh -y”

–WARNING–

This method breaks the Fog Client(s).

Tom and his amazingly amazing self helped me get the LDAP Plugin working.

@Tom-Elliott
Not right now; I’ve ran setenforce 0 for troubleshooting purposes for this and some other issues.

@Tom-Elliott
Seems to. I have:

ls -Za /opt/fog/snapins/ssl/

drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .
drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   ..
drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   CA
-rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   fog.csr
-rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .srvprivate.key

and
ls -Za /opt/fog/snapins/ssl/CA

drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .
drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   ..
-rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .fogCA.key
-rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .fogCA.pem
-rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0   .srl

@Jbob

…And I’ve officially hi-jacked this thread.

@Wayne-Workman said in FOG Client error:

I did and I have confirmed, time and time and time again. That’s why I said something…
My current theory is Firewall on the server side. I’m testing that theory now.

Theory blown. I disabled the firewall on both the server and client as well as yet again confirmed the server IP address. Still…same message. I’m open to suggestions…

@Wayne-Workman said in FOG Client error:

@TreyBentley make sure you set the fog address in the installer when installing. Leave the web root as default.

Failing to have these set correctly will produce the above described error.

I did and I have confirmed, time and time and time again. That’s why I said something…
My current theory is Firewall on the server side. I’m testing that theory now.

@Tom-Elliott said in FOG Client error:

@lionheart1986 I feel it must be added, 1.2.0 won’t work with the new client because the way the new client operates was only coded within the trunk versions. I want to say somewhere around SVN version 3k+ is when the new client work really got started. 2094 SVN was the release of 1.2.0.

Because of this, the new client will not work with 1.2.0 as the elements needed did not exist.

Okay… how about a situation I’m in. I’m on trunk and am still getting the error. Any suggestions?

@Junkhacker,

I’m sorry. It is indeed password protected; with and without that checkbox checked, ironically. We’ll live with that for now. Thanks. At least that was that simple. Now, time to go researching kernel panic issues.

@Junkhacker,
Yes, but I didn’t find that to be password protected…

@Junkhacker, no problem.

The goal is for the computer to pxe boot to a menu where the only option is to Boot to hard drive. However, if ESC (or other assigned hotkey) is pressed, then the Login Screen appears. After a Tech enters valid credentials, they’ll go to the Advanced Menu, where they can access the other, pre-defined menu items, like Host Registration, Quick Image, etc.

@Junkhacker , Well, yeah, nothing is there; but I didn’t think that would matter when I gave fog.reginput’s “Menu Show with” either Advanced Options or Advanced Login Required. Obviously I’m not understanding the boot menu configurations properly yet. I thought placing those with one of those options would populate the Advanced Menu. If not, where’s me some good documentation on it? ^_^

@junkhacker, The result is of http://fog.IP/fog/service/ipxe/advanced.php:

#!ipxe

Okay, here’s another one for you.

Whenever we try to access the Advanced Menu (Login) or simply Advanced Menu, we received either the following response or are sent straight back to the first boot menu:

Could not boot: Operation canceled (http://ipxe.org/0b2ce0a0)
Could not boot: Operation canceled (http://ipxe.org/0b2ce0a0)
Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds

How would one go about even starting to debug something like that?

OS version: CentOS 7
Apache version: 2.4.6
Fog version: trunk via Wiki
Revision: 7609
Hardware: VMware / vSphere

Okay, I’ll try and make this as clear as I can, but please feel free to ask for any clarification, and I’ll try and see what I can do.

---

My Server Info

• OS version: CentOS 7 (minimal install iso)
• Apache version: 2.4.6 (installed by Fog’s bin/installfog.sh ?)
• Fog version: trunk via Wiki (https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk)
• Revision: 7609
• Hardware: VMware / vSphere

Prerequisites

The material in this documentation assumes:

• Fog has already been installed and the web interface is fully accessible.
• The Fog server has sshd access and sftpd is working.
• You know how to extract files.
• You know how to transfer files.
• Maybe a few other things I’ve missed listing.

The Procedure

So, the ultimate goal was to authenticate only IT Techs, and via AD, so we could have yet another system with single sign-on. Research indicated that LDAP authentication should be fairly quick and easy with Apache.

Truth be told, I had to hunt down and find the exact version of some required files. I finally found them at rpmfind.net (ftp://rpmfind.net/linux/RPM/centos/7.2.1511/x86_64/Packages/mod_ldap-2.4.6-40.el7.centos.x86_64.html) and attempted to install the RPM with yum localinstall mod_ldap-2.*.rpm. However, whenever I tried this, the OS told me what version the file is, and what version the file needs to actually be.

They looked the same to my eyes, so, I downloaded the rpm on my Windows unit and opened it with 7-zip. I extracted the files and then transferred them to the Fog server, to /etc/httpd/modules/. Now, I don’t know if the next part was required, but it’s a habit. I updated permissions and access to the files once they were extracted and moved to their proper location:

chmod 755 /etc/httpd/modules/mod_ldap.so /etc/httpd/modules/mod_authnz_ldap.so
chown root:root /etc/httpd/modules/mod_ldap.so /etc/httpd/modules/mod_authnz_ldap.so
chcon -t httpd_modules_t etc/httpd/modules/mod_ldap.so /etc/httpd/modules/mod_authnz_ldap.so
chcon -t httpd_modules_t /etc/httpd/modules/mod_ldap.so /etc/httpd/modules/mod_authnz_ldap.so

In the end, my httpd.conf file looks as follows, using Christoph’s brain dump (http://www.held-im-ruhestand.de/software/apache-ldap-active-directory-authentication.html) as a guide. Loading the modules takes place first, in the LoadModules section.

nano /etc/httpd/conf/httpd.conf

..
...

LoadModule ldap_module /etc/httpd/modules/mod_ldap.so
LoadModule authnz_ldap_module /etc/httpd/modules/mod_authnz_ldap.so

...
..

The following takes place after DocumentRoot “/var/www/html”. Potentially sensitive material has been redacted and/or modified.

..
...

<Directory "/var/www/html/fog/management">

    # These options were here; I'm not messing with them.
    Options FollowSymLinks
    AllowOverride None
    Allow from all

    # Engage the initial connection with an account that can read the domain trees.
    AuthLDAPBindDN "ldapuser"
    AuthLDAPBindPassword yoursecretpasswordhere

    # Path to the AD/LDAP server. Includes the path as to where the above user can
    # search for usernames
    AuthLDAPURL "ldap://192.168.1.250/OU=People,DC=gtcc,DC=ad?sAMAccountName?sub?(objectClass=*)"

    # Standard authentication configurations.
    AuthType Basic
    AuthName "ITS FOG Server"
    AuthBasicProvider ldap
    AuthLDAPBindAuthoritative off
    AuthUserFile /dev/null

    # Users in the following groups are the *only* users allowed into the site.
    Require ldap-group CN=ITS Department,OU=ITS,OU=Groups,DC=gtcc,DC=ad

</Directory>

...
..

I found that next, I needed to run the following command to install some ldap tools that doesn’t come with a minimal installation of CentOS 7.

yum install apr-util-ldap -y

Then, restarted the httpd service:

systemctl restart httpd

With LDAP sign-in working, I was still getting the Login page (and rightly so). Editing the processlogin.class.php file will fix that right up. The code that follows attempts to perform the following:

• Rename what I came to believe to be the logout form.
• Make a connection to the Fog database and check for the username of the user that just successfully authenticated via Apache’s LDAP authentication process. The process I took here might should be updated to best practices standards. I’m not that great of a programmer, so I don’t know those standards.
• If no user is found in Fog’s user table, then add them; they’re authenticated via LDAP anyway.
• Adds username and generic password to the form input fields values.
• Hides the form input fields.
• Hides the Login button, placing a Please Wait… notice in its place.
• Javascript immediately submits the form.

nano /var/www/html/fog/lib/fog/processlogin.class.php
Line ~145:

..
...

# This was being double printed in the source code, and forcing a loop of redirection in the code below.
# Renaming the id to avoid that. It's probably for logout, anyways.
echo '<form method="post" action="" id="login-form0">';

...
..

Line ~153: after $this->getLanguages();, and replacing printf for mainLoginForm

..
...

# Make the username from Apache quicker to type.
$ap_user = $_SERVER['PHP_AUTH_USER'];

# Adding this password variable in, from the MariaDB result I got from manually querying
# the 'users' table. It should be the equivilent to "FogREMOTEUSER" and will be everyone's
# password with Fog, because they've already signed in with their AD credentials.
# However, I just realized this.... what if they need 'Quick Image'? Hmm... I guess I'll
# just tell them "FogREMOTEUSER", huh?
$ap_pass = '$2y$11$PIB.FzVsBSccSnoOVvyPcuPwJsHBYZRQO/RUFx.WinrCk0tQvb3IC';

# Connecting to the database the only way I know how. Maybe even re-inventing the wheel. Anyways,
# one does not simply walk into a database.
$DBServer = 'localhost';
$DBUser   = 'root';
$DBPass   = '';
$DBName   = 'fog';

$conn = new mysqli($DBServer, $DBUser, $DBPass, $DBName);

# Create the sql statement that will check for the user's existence in the database realm.
$sqlChkExist = "SELECT * FROM users WHERE uName = '" . $ap_user  . "'";

# Execute the query
$rs=$conn->query($sqlChkExist);

# How many rows where returned?
$rowCount = $rs->num_rows;

# If there were 0 rows, then we need to add this user to the database, then.
if ($rowCount == 0) {
	# Hey! Listen! ^_^
	# Looks like this user doesn't exist in this database. Let's add them.
	# Build the statement that will add the user.
	$sqlInsUsr = "INSERT INTO users (uName, uPass, uCreateBy, uType) VALUES ('" . $ap_user  . "', '" . $ap_pass  . "', 'autoGen', 0)";

	# Join me, and together we can rule the images, as SA and Tech.
	$rs=$conn->query($sqlInsUsr);
}

printf('</form><form method="post" action="" id="login-form"><input type="hidden" class="input" name="uname" id="username" value="' . $ap_user . '"/><input type="hidden" class="input" name="upass" id="password" value="FogREMOTEUSER"/><label for="login-form-submit"> </label><input type="submit" value="%s" id="login-form-submit" style="display:none;"/>Please wait....</form><div id="login-form-info"><p>%s: <b><i class="icon fa fa-circle-o-notch fa-spin fa-fw"></i></b></p><p>%s: <b><i class="icon fa fa-circle-o-notch fa-spin fa-fw"></i></b></p></div><script>document.getElementById("login-form").submit();</script>',self::$foglang['Login'],self::$foglang['FOGSites'],self::$foglang['LatestVer']);
# Troll the respawn, Jeremy.

...
..

I then realized that clicking the Logout button sends the user to the Login page, which then signs them back in. Since our Techs use their own computers, and the credentials go away upon closing the browser, I decide to remove the option to login. Simply comment out line ~52 of page.class.php

nano /var/www/html/fog/lib/fog/page.class.php

..
...

'about'=>array(self::$foglang['FOG Configuration'],'fa fa-wrench fa-2x'),
#  'logout'=>array(self::$foglang['Logout'],'fa fa-sign-out fa-2x'),
);

...
..

And according to my notes, that took me about… Eeyup, ~15 hours to figure out. Shows how bad I am at researching and debugging, I guess. But it works for us and what we’re trying to do! Again, please feel free to contact me about anything here; also, don’t be afraid to point out any typos. ^_^

Thanks!

I was planning to. I am still doing a little OU authorization tweaking, and wanted to try and implement passing the username straight to Fog with a generic password, like that top(?) response mentioned in the other thread. Once that’s done, I’ll try to orderly post the procedure I took.

I think I got it after more debugging and more research.

It turns out that I seem to have had my settings correct all along; I just needed to run yum install apr-util-ldap -y

None of the tutorials or stackoverflows ever said a thing about that. ^_^

I attempted to utilize the LDAP plug-in and got no where real fast. I saw someone else’s suggestion about using Apache to perform LDAP authentication. However no instructions on how to do so was provided. After too many hours of research and troubleshooting, I believe I’m on the home stretch. After getting passed some mod_ldap.so issues, I’m now having a hard time finding httpd.conf settings that apply to our set up; specifically the section with the AuthType, AuthBasicProvider, etc, etc, configurations.

If anyone was ever successful in getting this to work well, it’d be great if you could paste a redacted snip of your httpd.conf file with that section of settings. Or… provide a good alternative. ^_^

And, this sounds rude-ish but I honestly don’t mean for it to be, but before you go referring me to any website that attempts to show me what to do, please be aware that I more then likely have already been there and have already tried whatever they have on the page.

Thanks.

Fog version: trunk
Revision: 7609
bzImage Version: 4.5.3
bzImage32 Version: 4.5.3
OS version: CentOS 7
Apache version: 2.4.6