Best posts made by Sebastian Roth

@gwhitfield It’s not only missing a slash but /fog/ I suppose…

See here: https://forums.fogproject.org/topic/4354/fogscheduler-needs-started-manually-since-upgrading-to-svn-2912-from-1-2-0

@george1421 said in One central FOG server plus multiple Storage nodes in different locations possible?:

You can only capture images to the central server. The storage nodes are deploy only.

This is the most important point I think. From what @tesparza said so far it sounds as if image capture to storage nodes is wanted.

@atarone You need to disable secure boot in your BIOS/UEFI setup!!!

@RobTitian16 Maybe do some datebase cleanup: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

I’ll mark this solved as the AD joining issue is actually solved. Please open a new thread if you still have the group assignment issue after the DB maintenance.

Thanks for letting us know. Great that the wiki was helpful for you!

If you need further assistance please post the exact error messages you see and we should be able to help you out.

@paolom86 Secure boot is disabled?

@george1421 said:

The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware.

Unfortunately a lot of home router devices seem to do this stupid thing. I still have no idea why! We have spent a couple of days helping people to make things work with those kind of router. It’s just a pain in the ass - sorry for that.

Keeping my fingers crossed that you can make it work. Just let me know if you need some more advice.

@jmeyer Yeah, @Quazz is absolutely right. I did work in this and fixed it in dev-branch but haven’t found the time to do it for working-1.6 as well. Will do so soon!

Not sure about the menu but I think your init.xz/init_32.xz are way to small. Mine are about 1.5 times bigger (roughly 15 MB). Incomplete download of those files would explain the error you see I reckon.

cd /var/www/fog/service/ipxe
rm init.xz init_32.xz
wget -O init.xz "http://sourceforge.net/projects/freeghost/files/InitList/init.xz/download"
wget -O init_32.xz "http://sourceforge.net/projects/freeghost/files/InitList/init_32.xz/download"
chown www-data:www-data init*

@george1421 said in Which pxe file to use:

There is one other class of iPXE boot loaders, these are ipxe.kpxe and ipxe.efi.

From my memory it is mainly ipxe.pxe. But anyhow, your explanation is wonderful! May we borrow this text to update the docs?

Up until just a few years ago the SNP driver was very immature. […] But now the SNP driver in modern hardware is very good and stable, so the SNP boot loader is now recommended unless you have a UEFI computer older than about 5 years then ipxe.efi should be used.

@george1421 Good point! Should be update the default dhcpd.conf generated by the FOG installer as well?

@Flyer There is some more information on the difference between .pxe, .kpxe and .kkpxe in a dated wiki article (linking to an even more dated reference). We are in the process of updating the docs. Thanks for pointing this out.

@fredlwal Within your ~/project/bin directory you should have error_logs dir containing log files: ~/project/bin/error_logs/...

@jmeyer Just pushed the fixes to working-1.6 as well.

Please open the following URL in your browser and post the content here: http://ip.of.fog.srv/fog/service/ipxe/boot.php

@loosus456 said in FOG 1.5.0 RC 10:

So, just be clear: you guys don’t have a communications problem; it’s just that the whole world isn’t listening to you? Is that what you’re saying?

Quite frankly, it’s been a long time since I last got such an impudent comment. I spend most of my time at breakfast ruminating and I am over it. Such comments make me think about why I spend my free time working on the FOG project. I do this because I enjoy digging into problems. I am not here to discuss “if FOG is dead just because there hasn’t been a news post in the last two and a half months”. I myself won’t spend anymore time on such useless discussions!

Honestly, if someone is new to FOG or isn’t new to FOG but only has a passing interest, what do you think they’re going to go off? They’re not going to think, “Wonder what Tom Elliot is up to?” and then go scour the forums for your posts.

There is no need to follow anyone in the forums. New posts are answered daily and it’s pretty obvious without following Tom or anyone else.

@Maorui2k I think what you are looking for is in FOG Configuration -> FOG Settings -> General Settings. Look for FOG_QUEUESIZE and FOG_CHECKIN_TIMEOUT…

Why don’t you use multicast to send the same image to 40 PCs?

@george1421 said in using deploy image via pxe with more than two nics:

specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”

I guess you found a old bug thas has been in the code for a very long time. There really is no script called fog.quickimage in the FOS inits. Should be in /bin/ but there is non. So to me it seems like when the quickimage case is called it’s just ignored and fog.sysinfo is called.

The name was even updated in the schema at some point: https://github.com/FOGProject/fogproject/blob/65fe719e58f89398a1e3f45412d7305993eb282e/packages/web/commons/schema.php#L3315

@JJ-Fullmer said:

I tested this in a VM and recreated the problem. It didn’t matter if 1 or all adapters were connected, if 3+ exist on an unregistered host it behaves as @mosi describes.

What kind of virtualization do you use? I was not able to reproduce this on virtualbox yet. Seems like I am doing something wrong because when I get to an iPXE shell and let ifstat list the network interfaces I only see net0.

EDIT: Ok, got me. When using the default iPXE binary undionly.kkpxe this is not happening because it seems to only detect one network interface. Switching to ipxe.pxe brings up the same issue for me. What I noticed is that when you are asked to enter username and passwort to authenticate before the image deploy you submit with ENTER but get back to the same password dialog again with the information entered already. So hitting ENTER once again finally gets you past the authentication screen?!?!

EDIT2: Same problem when trying to join a multicast session on a VM with three NICs. Two NICs does not cause the trouble for deploy or multicast. Moving this to bug reports.

Have you tried searching the forums? This error is being reported many times. Are you sure your windows DHCP server is handing out the correct information (take a look using wireshark for example). Is tftp on your FOG server running and listening (netstat -antup | grep ":69")?

@george1421 @Wayne-Workman Thanks for your thoughts on this! Definitely helpful to get some more inspiration on this topic.

I guess we need to distinguish between different communications when talking about SSL. As George mentioned there are two (or actually three) different things communicating, one fog-client to FOG server, the other one IT admin web browser to FOG web UI and as third communicator there is iPXE to load the boot menu. The fog-client is using it’s own encryption protocol (HTTP within an encrypted tunnel based on certificates similar to HTTPS but not exactly like it!) since years and switching that to the official HTTPS standard is doable but not planned at the moment. The encryption used is state of the art and as strong as HTTS (SSL/TLS) is.

We transfer login password, AD credentials (when configuring those) and other things like that on the web UI communication and I definitely see that securing this should be easy to accomplish for users who want/need it. But we still default to plain HTTP partly because we provide pre-compiled iPXE binaries that cannot include a SSL CA trust certificate as every FOG server in the world generates it’s own CA on the first install. So delivering pre-compiled iPXE binaries is not possible. I have added a script (utils/FOGiPXE/buildipxe.sh) some time ago that is called to compile a full set of HTTPS enabled iPXE binaries embedding the “personal” FOG server CA into them. This works in most cases but it’s quite a heavy challenge if something goes wrong and we need to guide people through debugging this.

Perhaps it could be made easier to setup SSL, rather than forcing it? Perhaps make it optional, and defaulting to ‘no’.

Ok, that would be just renaming the option from force-ssl to use-ssl and ask for it as an installer question I reckon. Could do.

One of the things we are seeing with modern web browsers is that they are not liking self signed certificates. So every site you go to that has a self signed certificate you get the warning and have to click through a few screens to get to the site that employs a self signed certificate.

True, but let’s encrypt is not an option here as Wayne already explained. Maybe we should make it easier (provide a tool) to import the CA certificate into the browser store to get rid of the self signed messages. Not sure if that might cause other issues for users?!

Beyond SSL there are a few things that FOG developers could do it improve FOG’s security stance (i.e. mysql, secure password, firewall, etc).

Definitely a good point!!! Should fix that before we get into encrypting everything.

@Maorui2k From your description the issue could still be caused by some of your machines instead of the switch being the bottleneck. Again, I am not saying that switch isn’t causing this. Just want to point out that testing PCs in batches doesn’t cost you money (like a new switch would) but only some time.

Multicast in FOG works pretty similar to how Ghost does it. Although back at my old working place we had strange performance issues which we never had using FOG multicasting!