Posts made by Tom Elliott

No problem.

That’s what I’m hoping to be here for, to help others out.

OK.

Has anyone in this thread found this issue with 0.33b? Maybe I can append/sed the command into the installation so nobody has to worry about this!

Lol,

I didn’t know being the center (or centre for those in the European regions) was such a big deal. After all, I’m the center/centre of the world. (JK)

Try a different kernel. That’s at least seeming to work for many others. I’ve built one doesn’t rely on the Video cards so should display something the entire time:

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

This file will go in the file system under:

/tftpboot/fog/kernel/

Just make sure you make a copy of your current one by doing:

cp /tftpboot/fog/kernel/bzImage /tftpboot/fog/kernel/bzImage.orig

Then run:
EDITED FOR PROPER SYNTAX (SORRY)
wget --no-check-certificate -O /tftpboot/fog/kernel/bzImage [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url]

Then try to do the task you’ve been attempting.

Add the caveat now to Fedora 19, being that they changed the database (mysql) to mariadb. All works, but requires minor changes in the script. I’ve already created a thread pointing out the issue with Fedora 19 and a fixed tarball for it based on FOG 0.33b, though the same changes could just be made in 0.32.

So the tftp boot menu never appears on a client system?

The slowness on the interface is what was thought to be indicative, but now it sounds like you have your setup to be FOG as the DHCP server. However, how are your clients connecting to FOG itself? Are you behind a router, switch, hub? If you’re in a router, you’ll need to tell your router to point to your fog server and pxelinux.0 for dhcp-boot. If you’re on a switch where the FOG Server is the DHCP server, you’ll need to make sure that firewalls are disabled on the server. Otherwise your server is blocking attempts for requests for DHCP.

We still need more information I think.

The 45 seconds you’re seeing in delay is due to the kernel having drivers setup for scsi systems as well and it’s actually checking for alternate ATA device connections. This is normal and expected behavior.

When you’re mounting the init.gz, follow these steps:

gunzip init.gz
mkdir tmp
mount -o loop init tmp
vi tmp/bin/fog
:606
i#ESC
:wq!
umount tmp
gzip -9 init
rm -rf tmp

You should be good to go.

Windows commands always do. Good thing for SAMBA.

net use z: \<location of drivers> <ADPASSWORD> /user:<ADUSERNAME>

This is for a Hardware (mostly) independent image. So theorethically, you would just create a VM. It’s network drivers should work with any Windows.

Change the ADPASSWORD and ADUSERNAME info out for your novell stuff.

This script is run before the image is uploaded. So basically, the image comes prepackaged with all the needed drivers.

We have a network share that we just placed all the drivers, but this could easily be changed to be right on the

@echo off
net use z: \<location of drivers> <ADPASSWORD> /user:<ADUSERNAME>
for /r z:\ %%i in (*.inf) do pnputil -a %%i
net use /del z:

Thanks,

The version, that you already downloaded (my guess) is 3.10.10, I just uploaded a new 3.11 kernel same link.

My understanding of this is that it changes the name by editing the registry key’s directly within the fog system. This is nice as it doesn’t require the system to contain the FOG Service client. However, I think the pertinent part here is that it’s a part of the FOG script.

From the fog script:
if [ “$capone” != “1” ]; then

                                    changeHostname

Then from /usr/share/fog/lib/funcs.sh

changeHostname()
{
echo -n " * Changing hostname…“;
if [ -n “$hostname” ]
then
mkdir /ntfs &>/dev/null
regfile=”“;
key1=”“;
key2=”";
if [ “$osid” = “5” ]
then
ntfs-3g -o force,rw $win7sys /ntfs
regfile=$REG_LOCAL_MACHINE_7
key1=$REG_HOSTNAME_KEY1_7
key2=$REG_HOSTNAME_KEY2_7
elif [ “$osid” = “1” ]
then
ntfs-3g -o force,rw $part /ntfs
regfile=$REG_LOCAL_MACHINE_XP
key1=$REG_HOSTNAME_KEY1_XP
key2=$REG_HOSTNAME_KEY2_XP
fi
reged -e “$regfile” &>/dev/null <<EOFREG
ed $key1
$hostname
ed $key2
$hostname
q
y
EOFREG
umount /ntfs
echo “Done”;
else
echo “Skipped”;
fi
}

The reason you’re not seeing it get changed in quick image is that runs a different script called fog.quickimage. On reboot the task doesn’t set the $hostname variable which is to be skipped. The only way, I could think, to get this is to comment out the changeHostname field in /bin/fog of the init.gz on line 606.
[COLOR=#000000]if [ “$capone” != “1” ]; then

                                    changeHostname[/COLOR]

[COLOR=#000000]if [ “$capone” != “1” ]; then

                                    changeHostname[/COLOR]

[COLOR=#000000] [/COLOR]

Gilou et al.

Well said.

I agree that we need to maintain the current setup. If Chuck so decides to make it an individualized application, that’ll be fine and I think we have enough of a community here now that we’d make a fork of the current state of FOG just for familiarity sake, should that not be much of an issue to the original creators.

I love the fact that this system uses linux. If only for the part that we merely need to install the required packages. The current setup allows us a, relatively, painless method of install by using the scripts, but ultimately the script is just used for the simple configuration and installation of packages. If we know which packages are needed, we could conceivably make this less distribution dependent by installing via source. This could also be handy if we have the source setup to install for FOG style file systems on the linux host as it provides a means for a centralized location rather than the standard file system for basic services, such as http, mysql/maria, php, tftp, and NFS.

I understand what you mean when you state NFS is the security hole presently and completely agree, though the current 0.32 and 0.33 still install vsftp as the directory. Why not just use ftp to send the files? My only guess to why we use NFS is because the filesystem can be mounted like a regular disk and information transferred that way. However, we create a fog user on the linux system and setup a password for this user, why not use ftp? It would help close the big hole in allowing anybody to mount and write/delete items from the image store.

I’ve played a bit with gpxe, pxe, and ipxe. I didn’t see much change in loading the bzImage and init.gz file but again I also didn’t try loading an ISO. The idea of integrating gpxe/ipxe into the system is quite nice in that it would, conceivably, allow for cross country imaging and management of systems. You’re not relying upon the idea of keeping the imaging within the same network, you just point to the [url]http://<ip/hostname>/{bzImage,init.gz}[/url] file and the host is loading. Though this method could hurt as it would assume all network cards support gpxe/ipxe by default which they do not. The current method many use over standard PXE is chainloading gpxe with a file called gpxelinux.0 This still boots as regular tftp until the gpxe picks up, then it can point to the http.

I hope we keep the FOG system under the current methods. A web interface to work with is a lot simpler, IMHO, to operating FOG. It allows a method of remote management if configured properly. Basically, I can set tasks up within my network without having to physically be at the location. Going to an individualized application method would kind of thwart that ideology.

I do use memtest and clamav, but I don’t think the current system is feasible. I’d say mount a temporary share and have the server run the clamav system itself. Using the init.gz file to host clamav is a bit cumbersome at best because it rely’s upon the system not updating the actual files running which it does rather frequently. So embedding the init.gz file with A version of clamav may work at first, but after a little while it becomes outdated. Using the server to perform the tasks make a bit more sense and it’s easier to upgrade one system, and you’re not forcing the init.gz system to download (temporarily mind you) the latest signature/virus risks.

No problem, I hope the best.

Go to the directory:
/tftpboot/fog/kernel

Copy the original kernel as backup;
mv bzImage bzImage_orig

Wget the new kernel in the directory:
wget --no-check-certificate [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url]

You should be set.

You need another kernel that has the driver for that system embedded.

You can try the kernel that I created that has all of the network drivers available for linux built into it.

[url]https://mastacontrola.com/fogboot/kernel/bzImageALLNET[/url]

Just rename it to bzImage in:
/tftpboot/fog/kernel/

Happy Paste Eating!