Posts made by Tom Elliott

@george1421 forgive me if my thoughts are incorrect, but I don’t think this is a big issue, though it should ask for it, I like that it doesn’t set a password like it did for me a while back.

The root user is usually defaulted to only be allowed by the local host now, so it not having a password isn’t a huge issue. As fog now defined and sets up a separate user, and doesn’t rely on the root for fog related items, I think this is okay.

Maybe running mysql_secure_installation should be run or suggested to run after fog installs?

@george1421 snapin tasks are exactly that, tasks. That means you need to task the host with a snapin task tasking: deploy, all snapins, and single snapin.

@george1421 snapinJobs is the task table for snapins. snapinTasks are the individual snapins associated to the snapinJob.

Persistent groups wouldn’t create this entry, this is created by the host at the time a task is generated.

@joyboy11111 I’m going to guess, and no judgement intended please, that you’re not overly familiar with VI/VIM for editing file?

type these commands:
/ipxe.efi

Press enter

Note the/ = search everything after.

Once you find the line line arrow over to the area to edit and press the i key, Press delete over the ipxe.efi then type snponly.efi

Note the i = insert to leave “insert/edit” mode press ESC key

Press the esc

Type :w

Note the : puts VI into "command mode. w = save/write file.

To exit VI type: :q

Note the : puts the VI into "command mode. q = quit.

@jdnoble18 Why are you connecting using the fogstorage user? You should be using the fogmaster user to run the db cleanup commands.

@alesser Not really unfortunately.

The token you see on the screen is stored in the fogserver in a different mechanism. What you see is an encrypted string compared to what is actually stored in the FOG Server.

If you have the original “plain text” value, it should work (even if you don’t see the same key) as it’s still referencing the same “plain text” value.

@btoffolon What version of FOG are you using? The init error your seeing would seem to indicate you need to change the init ramdisk size from 127000 to 275000. This can be done from FOG Configuration Page -> FOG Settings.

If this is already set to 275000 then it would seem the full init wasn’t downloaded.

@devrick The funcs.sh script resides on the init folder, not on your local server.

@seppim To further clarify,

TFTP is a limited protocol. What do I mean by this? Well it transfers data in blocks. As each blocksize is met, the TCP needs to resend validation of the next block. By default, tftp is set to check ever 512 bytes. So for every .5 KB it’s chunking, checking the prior, receiving the next, then downloading, and rinse repeat. At 1.3 GB this is going to take a very long time.

Now there are methods to increase the block size. I believe the maximum block size, however, is 65536 Bytes. That means, essentially, every 64KB it will have to do the chunking process over and over. Still would take a long time with a 1.3GB file, though it might decrease the download time from 15 minutes to maybe 7.5 minutes (I’m just using numbers as a baseline, I have not tested this.)

We use iPXE because the download sizes for TFTP to get the iPXE binaries is much much smaller. The UEFI driver ipxe.efi is 1,020 KB (basically 1MB). The Legacy driver undionly.kpxe 96.6KB (or about 97KB). I believe the UEFI stack takes so long to load because of this size difference. The efi driver is roughly 10 times larger than the legacy item. Even the legacy ipxe.pxe driver is only 352KB.

So once the ipxe stuff is loaded, you are then having access to TCP protocols, not limited to TFTP items.

@seppim TFTP is a protocol that is limited to 10Mbps. That’s why. If you need more speed, you should chainload from TFTP to iPXE which will then use HTTP/TCP protocols to transfer the data, giving a much faster load time.

@julio said in droit:

bonjour voici mon fichier /etc/exports. j’ai ajouter ces deux dernière lignes pour un test mais elle ne fonctionne pas toujours.

I’m not quite sure what you’re looking for.

First things first, the fsid elements must be unique.

Meaning these lines are good.:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

But the following 2 items are not good as they are overwriting the configuration for the first 2 items.

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Should more likely be:

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=2)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=3)

@cyril An easier method:

Boot the machine into windows normally.

Windows Key + R
msconfig
Boot -> Check Safe Boot
Click Ok
Restart machine and get into bios
Change storage mode to ahci
restart machine and boot windows
Windows Key + R
msconfig
Boot -> Uncheck Safe Boot
Click Ok
restart machine and make sure it boots into windows properly.

I realize there may appear to be more steps, but they’re much easier to follow and understand.

Steps are here:
https://forums.fogproject.org/topic/14177/imaging-an-ssd?_=1608818295408

@astrugatch et al.

An OVA would be a decent approach, but then it puts the onus back on the FOG developers to manage the OVA, manage the updates, make sure documentation is all up, while also maintaining the FOG GUI and imaging system.

While the OVA approach is seen as a “yeah that would make my life easier” it doesn’t really make much sense.

If anything, a docker container would probably be a better and more security based approach. It allows us to work in one relatively simple environment. There’s some complexity involved here as well of course, but no where near as much as it would be to maintain an entire Virtual Appliance along with updates to the OS, managing templating and customization features, managing upgrade paths, etc…

Ultimately, the goal is to move away from a linux required environment (and I have been slowly working on it as well) and migrating from PHP based GUI/API to a NodeJS based GUI and API. This means you could install fog using simple management commands with being OS agnostic such as: npm install fog-node (or something like that). This could be done on Windows, Mac OS X, and/or linux using a common path. Plus it removes the onus of OS management giving it back to the Administrator.

The docker container, I think, is the middle man approach that would accomplish a similar feat as OVA without as much overhead for management though. Plus, realistically, it can be done much quicker and compartmentalizing more of the components such as TFTP, NFS, HTTP/S, etc…

@threeonesix As @sebastian-roth suggests, leave the locations default. /home/images /home/snapins is changing the default locations.

FOG defaults to put images on /images and snapins on /opt fog/snapins

If you are a beginner, why state where you want these things mounted instead of saying, I would like images on /dev/sdb and snapins on /dev/sdc. You have admitted to not knowing much about linux.

To understand:

/dev/sdb = /images
/dev/sdc = /opt/fog/snapins

That would get you where you need to be, all you need to learn is how to tell your server to mount /images and /opt/fog/snapins.

First things first, did you make sdb a single partition using all available space for the partition? How are you formatting the partition? xfs, ext2, ext3, ext4, ntfs, btrfs?

Same questions for sdc

The following instructions assume you are going to use /images and /opt/fog/snapins as the installer defaults to. It assumes the partition is formatted on both disks as ext4. Adjust as necessary.

sudo -i #enter sudo password

mkdir /images #creates /images if it does not exist already
mkdir -p /opt/fog/snapins #creates /opt/fog/snapins if it does not exist already

echo "/dev/sdb1 /images ext4 defaults 0 0" >> /etc/fstab # appends the quoted line into the /etc/fstab file
echo "/dev/sdc1 /opt/fog/snapins ext4 defaults 0 0" >> /etc/fstab # appends the quoted line into the /etc/fstab file

mount -a #attempts to mount /dev/sdb1 to /images and /dev/sdc1 to /opt/fog/snapins

@detoss so getting very much details.

-rwxrwxrwx is what you see files appear as. Similar for directory but the 1st dash will usually be a d, denoting directory.

Notice there are 3 groups of rwx.

r=read=4
w=write=2
x=execute=1

First grouping rwx (left to right) = owner
Second grouping rwx = group
Third grouping rwx = other/everyone

So to make owner group and other have max permissions

777

Does this make sense or at least start to help?

There are other pieces to this but this is most likely what most people want to understand.

The chmod command is short for change mode. Mode here basically means permissions.

@plegrand Groups do not track what snapins are associated to them. It’s just too complex to get right and extremely error prone. Even the things that do track it’s extremely tedious.

Why you ask?

Well, let’s just use some medium numbers to show what I mean.

Let’s say you have a group with 500 hosts in it.

You originally setup the group so all hosts had the same snapins. (Easy to do, just update the group accordingly.)

Now you go to one of the hosts directly, and you remove the snapin from that host. Now you go back to the group, and the group now doesn’t know anything about the snapin on all 500 hosts.

Remember, groups in FOG are not a persistent thing. This is because you can associate a host to multiple groups. Groups, in FOG case, is basically a mechanism to mass update hosts.

For example:

One group to set machines up for specific snapins, but another group that you want to set machines printers, (the machine sets are different, but you might want to cross machiens.)

@george1421, @Oleg, @Sebastian-Roth The large majority of the time, the only changes are gui based.

So, I have a script I run, that allows me to switch just the GUI/web facing stuff, between one another. So, for example, most of the time, my environment runs working-1.6. But when I need to edit something in dev-branch I do these steps:

1. switch branches from working-1.6 to dev-branch.
2. swap out my GUI facing things
3. make the needed change
4. update dev-branch
5. switch branches from dev-branch to working-1.6
6. swap out my GUI facing things

Offline installer could do something like that, just we need to ensure the end user copies the inits and have a specific location for them within the unpacked tarball. Of course we haven’t coded for this yet, so the best I can do for right now is basic steps to get there.

1. Download the tarball on USB stick, or whatever.
2. Download the Inits and hash files on same USB stick
3. Download the Kernels and hash files on same USB stick
4. Download the FOG Client installer(s) and hash files on same USB stick
5. Extract the tarball.
6. Place, as appropriate, the inits, kernels, and fog client installers into the extracted location.
7. Do everything we normally do, just without the package update/install process. ANd without downloading the stuff we pulled above.

For my script I do:

#!/bin/bash
path=$1
configpath=$2
[[ -z $path || ! -e "$HOME/$path" ]] && path="$HOME/fogproject"
[[ -z $configpath || ! -e "$configpath" ]] && configpath="$HOME/config.class.php"
[[ ! -e "$configpath" && -e /var/www/fog/lib/fog/config.class.php ]] && cp /var/www/fog/lib/fog/config.class.php $configpath
[[ ! -e $configpath ]] && {
    echo "No configuration file available. Please make sure this file exists"
    exit 1
}
rsync -a --no-links -heP --delete $path/packages/web/ /var/www/fog/
cp $configpath /var/www/fog/lib/fog/config.class.php
chown -R apache:apache /var/www/fog
chown -R fogproject:apache /var/www/fog/service/ipxe

It can take 2 arguments.
1st argument is the path to copy from. If the path does not exist or is not defined, it will assume $HOME/fogproject is the path.

2nd argument is where the config file will be copied from when copying back the data. The the configpath is not defined, it will assume $HOME/config.class.php. If the file does not exist at $configpath, it will copy the file from /var/www/fog/lib/fog/config.class.php and place it at $configpath location. If the $configpath does not exist, it will exit the script as we don’t have a config that will allow the web folder to work properly.

Of course there’s some minor issues (all which can relatively easily be edited or add more argument controls. Such as web path, user (apache vs www-data vs nginx vs. etc…)

@seppim If you have the FOG client installed on the machine, you don’t need a snapin task to tell the machine to reboot. The fog client will do that automatically for you.

@seppim If you have a specific snapin that needs to be run on a machine, but then you have a PXE type task you need to run (such as deploy), I guess I don’t understand the point?

No you cannot have 2 tasks for the same host active at the same time. The only, kind of, exception is specific to snapin tasks. You can schedule multiple snapin tasks at one time. (though it has been a while.)

If you need the snapin task to run after the pxe process completes, why not just add the snapin to that host. When you create a deploy task, it will automatically queue the snapin tasks for you once that previous task completes.

@tech04 If secure boot is disabled on the machine, maybe re-enable it now that imaging is done?