SOLVED why is fog 1.3 asking for a username and password to get to the fog menu? i cant find a setting at all to turn this off
-
Server
- FOG Version:
- OS:
Client
- Service Version:
- OS:
Description
-
Luckily this wasn’t due to a schema issue or anything.
This was due to somebody installing the capone plugin from a much older version of FOG but with recent changes, it was still in place just looking at the wrong places for values.
Removed the capone plugin and all is well.
-
@Tom-Elliott I seemed to recall this same exact issue in another thread. I’m pretty sure this was the solution then too. I could not find that thread for the life of me, but I know we did see this issue before. As FOG turns 1.3.0 we should get this documented somewhere in a faq that users can find easily.
-
Luckily this wasn’t due to a schema issue or anything.
This was due to somebody installing the capone plugin from a much older version of FOG but with recent changes, it was still in place just looking at the wrong places for values.
Removed the capone plugin and all is well.
-
@Tom-Elliott could be it said you been inactive for 4 months lol
do you have any other ideas what i can do to fix this? -
@darkxeno I don’t see the message. Maybe you’re talking to the wrong account?
-
tom i sent you a messge on google talk
-
@darkxeno <?php
/**- Boot page for pxe/iPXE
- PHP version 5
- @category Boot
- @package FOGProject
- @author Tom Elliott tommygunsster@gmail.com
- @license http://opensource.org/licenses/gpl-3.0 GPLv3
- @link https://fogproject.org
/
/* - Boot page for pxe/iPXE
- @category Boot
- @package FOGProject
- @author Tom Elliott tommygunsster@gmail.com
- @license http://opensource.org/licenses/gpl-3.0 GPLv3
- @link https://fogproject.org
*/
require ‘…/…/commons/base.inc.php’;
header(“Content-type: text/plain”);
$mac = array_merge(
explode(’|’, $_REQUEST[‘mac’]),
explode(’|’, $_REQUEST[‘mac0’]),
explode(’|’, $_REQUEST[‘mac1’]),
explode(’|’, $_REQUEST[‘mac2’])
);
$mac = array_filter($mac);
$mac = array_unique($mac);
$mac = array_values($mac);
$_REQUEST[‘mac’] = implode(’|’, (array)$mac);
$Host = $FOGCore->getHostItem(false, false, true);
FOGCore::getClass(‘BootMenu’, $Host);
this the boot.php file
-
@Tom-Elliott its still doing it
-
@Tom-Elliott give me a few to re run it
-
@darkxeno And you’re 100% sure you upgraded from 1.2.0 to 1.3.0-RC-37?
I know this sounds stupid but I installed 1.2.0 and then upgraded to 1.3.0-RC-37 and am not seeing the same issue you are. This tells me the Schema update is working properly.
So I must ask the questions here.
Maybe try removing the /var/www/fog and /var/www/html/fog directories and re-run the installer? I am not sure this will fix the issue but it would help ensure the data is in a known state.
Please I’m not questioning your capabilities but I must know what is actually happening.
-
#!ipxe
set fog-ip 10.0.0.22
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x1b
iseq ${platform} efi && set keyName ESC || set keyName Escape
prompt --key ${key} --timeout 0 Booting… (Press ${keyName} to access the menu) && goto menuAccess || sanboot --no-describe --drive 0x80
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://10.0.0.22/fog/service/ipxe/boot.php##params -
@darkxeno 10.0.0.22/fog/service/ipxe/boot.php
-
@Tom-Elliott yeah thats the ip
-
@darkxeno on the ipxe if i put a user name and password on the boot menu it goes to the menu but on the web browser it says it can be found
-
@darkxeno 10.0.0.22 is your FOG Server IP?
-
@Tom-Elliott 404 page not found
-
What is output if you go:
-
@Tom-Elliott this came from upgrading from 1.2
-
@Tom-Elliott yesterday after the upgrade and it was an upgrade
-
WHen did this start happening? Is this a fresh install or upgrade? Did this issue only occur from 1.3.0-RC-36 to upgrade to 1.3.0-RC-37?
Sorry a lot of questions, but from the sounds of things, this is an issue from a far earlier RC release where the schema wasn’t updating properly. We need a lot more information.
