Posts made by moss

I’m using 0.32 but under:
Other Information - Fog Settings - General Settings
There’s an option called: [FONT=Ubuntu][COLOR=#333333] FOG_HOST_LOOKUP[/COLOR][/FONT]
Setting that to 0 will disable host pinging

I’m no Linux expert but htop is a great program to display real time CPU/memory usage.
iftop and nethogs do real time bandwidth/network monitoring and nmon does a bit of everything.
All can be installed using apt-get and all will run from the command line.

I don’t really understand what you’re asking, what passwords specifically? Although I cant recall many threads about confusion with passwords.

The only passwords I can think of are:
PXE menu passwords
Web interface passwords
AD/Fog Crypt password
SQL passwords

All of those are fairly straight forward to use/understand and require virtually no maintenance after initial installation.
I’ve encountered various issues on Fog whilst I’ve been using it, virtually none have been related to passwords.

Although I no way am I having a go at the community, about a year ago the project did seem to be almost dead (even so, 0.32 was and still is working flawlessly for us) however the team have done a magnificent job since then and the recent activity has been outstanding.
I can understand why those who haven’t been around recently would assume the project was dead.
I do agree its a shame other communities haven’t seen the recent progress as I’ve found Fog puts many commercial products to shame.

I’m getting the same error:
[url]http://fogproject.org/forum/threads/ftp-issue-when-uploading-images-to-san-fog-0-33b.10370/[/url]
I did try pulling down the revision suggested but the error persisted, I’ve not tried anything since though as I’ve been too busy wit other work.

I was running 1491, just checked out 1493. Testing now.

Thanks.

Checked out the latest revision using SVN.

I’m still getting the same error with the latest revision.

Its purely a test setup at the minute, we have a live Fog setup running on Ubuntu 10.04 LTS which has been running for years.
Its likely we’ll go with 14.04 as a production server in the future but [SIZE=2]the old server will still be available as a backup.[/SIZE]

I’ll try a newer revision now, thank you.

Not sure if this is the best sub-forum to use but I suspect its not really a Fog bug and more due to the fact my images are stored external to the server.
My current test setup is Fog 0.33b and Ubuntu Server 14.04.
/dev/sdb1 is mounted as /images (/dev/sdb1 is an iSCSI target on a SAN)

I’m having a similar issue with FTP as noted here:
[url]http://www.fogproject.org/wiki/index.php?title=FOGUserGuide#Separate_NFS_Server[/url]

The image uploads as it should then I get a never ending FTP authentication error (not the same as the one listed in the Wiki):
[CODE]FOGFTP: Login failed, Host: fogipaddress, Username: fog, Password: hashedpassword, Error: ftp_login(): Login incorrect,[/CODE]

Doing as the Wiki says an moving/renaming the uploaded directory works but it the fix listed appears to be for Fog 0.32 as Post_Stage2.php is completely different in 0.33b comparing it to our live 0.32 server.

Makes sense, that first machine displays the menu for about a second now, something must be hanging prior to it loading. Its not an issue at all really as I always adjust the timeout upwards.

It may have been a one off as on other machines its defaulting to 3 seconds as it should, on the other machine the menu was disappearing after less than a second.
I always increase it to 60 seconds as we don’t PXE boot by default.

I downloaded the latest release but didn’t do a full re-install, I copied the revised file into my existing installation. The boot menu now displays but it appears to have a very very quick timeout. It started to boot from hard disk within a second of the menu displaying.
I repeatedly pressed the arrow key while PXE booting to change the default option and the menu appears as it should, I know how to change the timeout so its not huge problem on my installation but I’m not sure if its something that needs addressed.

Thank you for the quick response and fix.

Thank you very much, I’ll give it a test now. If successful, this has to be one of the quickest bug fixes ever!

I’m currently testing Fog 0.33b on Ubuntu Server 14.04.
When PXE booting the machine seems to communicate with the Fog server, however once its got an address the next part fails. It happens too quick to see the actual error on a physical machine and with a virtual I had to record the session and slowdown the playback to see the error.

The Fog PXE boot screen shows very very briefly (less than quarter of a second) and displays the error in the attached file.
Then it displays a generic PXE error:

On the VM: FATAL: Could not read from the boot medium! System halted
On a physical Dell PC: Selected boot device failed. Press any key to reboot the system.

[url=“/_imported_xf_attachments/0/676_Capture.png?:”]Capture.png[/url]

I’m currently testing 0.33b in a production environment.
The refreshed web interface looks great the only thing that slightly bugs me is the new logo and text pushes the menu and graphs further down the screen than in previous versions. I know this wont be an issue on higher resolution screens but on lower resolution screens it seems a waste of screen real estate.

I understand if it stays that way as its such a minor issue that wont bother the majority of users and for those of us that it does bother changing it should be easy anyway.

Although my Python skills are limited (but improving!) this could be really useful, I had looked to do something similar a little while ago but didn’t really know where to start.
Thanks!

Possibly a bit of a noob question, why would I use an x64 kernel over an x86?
I know the reasons why I’d use a 64bit OS over 32bit, but don’t really understand why a 64bit kernel would be needed with FOG, are some of the drivers 64bit only?

From a quick search it appears most people do it the other way, using SCCM as the primary PXE server, although the following post does have a little info on doing it the other way.
[url]http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/#comment-14629[/url]

My justification for using two PXE servers is a pretty poor one really, I know FOG handles PXE nicely but I know very little about SCCM and how it handles PXE booting. I wouldn’t be surprised if Microsoft have some convoluted method which would require lots of work to migrate to FOG.