When I re-designed the boot menu, I created all the different elements I could think about. The intention, hopefully, for advanced menu was you could create menu’s like everything else and associate them to the “advanced” side. That said, I still don’t have a good understanding of how to implement a menu system that would link to the advanced system. The item is designed, but not flushed out. So for right now, the “Advanced” and “Advanced Login” are essentially simple placeholders for a feature I might get to think about and implement down the road. Mostly, these days, I’ve been more worried about working out bugs and minor things for 1.5 while working toward getting 1.6 to a more suitable testing state.

Mind you (et. al) that I just started a new job and have much less time than in the past to actually work on FOG. This doesn’t mean I won’t work on it, simply that I’m very busy during the working week and by the time I get home it’s nearly time for bed already

Hopefully this helps you understand the ideology, even if it doesn’t work quite as I would have hoped (or as anybody might expect.)

@Fernando-Gietz said in Multicast data address not change from one task to another one:

Se añade esta linea para que asigne direcciones IP diferentes a cada tarea multicast

I’ve added the patch, but a little more checking involved. This has been added to both the working and working-1.6 branches. It tests the set value for the $address variable. If this variable is set, it will calculate the address. Here’s the snippet of lines:

if ($address) {
    $address = long2ip(
        ip2long($address) + (
            (
                $this->getPortBase() / 2 + 1
            ) % self::getSetting('FOG_MULTICAST_MAX_SESSIONS')
        )
    );
}

Hopefully this will address the problem people have been seeing and allow the use of multiple sessions.

FOG Uses port 445 to detect the status of the client machines. This is usually UDP, though I think opening UDP and TCP would help things out.

We use this port as it can give a more direct status than a simple ICMP request.

Hopefully this help.s

@JGallo As you typically re-run the FOG installer, the restart of the service is already performed and therefore not necessary. I’d recommend letting it cycle once or twice on it’s own, then upload the logs. This will let us know if it’s working as it should. By restarting the service to “speed” things along, we actually only see “initial startup.” While, functionally, they’re the same thing, it’s just good to know the full time operation is working as expected as well.

@blindcat420 can you run a simple tftp transfer test? First can you double check rpcbind is running? Usually, I see tftp in a call port created when requested rather than a constant seeing of port 69 being open. This is usually handled by rpcbind utility. Xinetd May play a role as well but I don’t know if it running alone will prove anything.

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Testing_TFTP

@Les https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

Please start there. Mind you this thread is very old and while the message you’re seeing may be similar, hence my posting to the wiki article, chances are your circumstances, version, file, etc… are vastly different. It’d be recommended to open a new thread.

@thegiantcat can you get an exact screen shot of your /etc/wgetrc file?

If you literally have:

"no_proxy="localhost""

This may be a part of the problem.

I’d imagine you should have:

no_proxy=127.0.0.1,localhost,localhost.localdomain,X.X.X.X

Change X.X.X.X to whatever your fog IP actually is.

Also, I believe the installer uses curl for binaries and database backups, so I imagine editing the /etc/wgetrc is the wrong approach.

I believe you would edit the file for whom you’re installing at:
~/.curlrc

You could set the same information up in /etc/skel/curlrc too I suppose.

however you’d want lines like:

proxy = <proxyInfoHere>
noproxy = localhost,127.0.0.1,localhost.localdomain,127.0.1.1,X.X.X.X

You could also edit your ~/.bashrc To contain lines like:

 export http_proxy=<http://proxyInfoHere>
 export https_proxy=$http_proxy
 export ftp_proxy=$http_proxy
 export rsync_proxy=$http_proxy
 export no_proxy="localhost,127.0.0.1,localhost.localdomain,127.0.1.1,X.X.X.X"

If you do add to the .bashrc file, however, you’ll need to close the terminal/logout of the console, and log back in for the changes to take effect.

Hopefully this helps.

In the case you use the bashrc method, please change the X.X.X.X to that of your fog server’s actual IP address, and of course change your http_proxy line to be appropriate. It should include the schema (http{,s}://…) information as well.

@astrugatch Yes, as it’s signed by the CA, it shouldn’t have any issues. Though you may need to have it initially recreate the private cert as it likely created it using the IP. Just a good to know thing for the future. (Particularly on fresh installs.) It would mean, however, that you’d have to update all your clients which could prove problematic in general.

Could be simpler just to remove the IP checking during fresh install. Or, maybe we could add a Hostname item as an inline option (or add to the /opt/fog/.fogsettings file of course) the builds a cert using the IP and allows an alternate name within the cert using the hostname.

Of course this is just thoughts being spewed out sorry.

@thegiantcat What’s the installer’s error log look like?

It should show us more information as to why backing up is failing.

I am a little confused too. Is your FOG Server also your PROXY machine?

What version of FOG are you running?

Have you tried troubleshooting FTP information?
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@fogger1 The links that are provided are the init’s in the most current state we have. The good thing is now that the init’s are separated from the main elements of FOG, and changes aren’t quite as frequent as the main elements, the init’s being provided should work with any 1.5.x version of FOG and even the 1.6 as the backend “functional” pieces aren’t being modified at the same scale between the two versions. So they’re not provided for 1.5.4, they’re whatever the most current version is. The init’s are not labelled in the same fashion as our normal releases which is why it’s important for the distinction here. The init’s in the links are what are provided for 1.5.5 and 1.5.5.2 (which is the most current dev-branch version).

@Sebastian-Roth The problem with the password was the complexity requirements that were enabled.

It would require 3 of the 4 main common things, but the first/last character of the password did not count toward the system’s configured password complexity requirements.

I used one that it suggested and updated the fields where needed.

This is not a common thing of course.

The other part of the problem was the old ‘two versions’ of FOG installed on the machine.

Essentially both /var/www/fog and /var/www/html/fog were individual installations. My guess is it was using the /var/www/html/fog version for display, but the fog configuration page was coming from the link.

Moved both the /var/www/fog/ and /var/www/html/fog folders and ran the installer and all completed properly.

Tested the use of FOG Configuration and updated the passwords where needed. All was working properly now.

@Sebastian-Roth no there’s no option to use the old style GUI. Although theming should work but would take a lot of effort.

@kboutelle There’s the problem.

You have /images and /images2 mounting to the same File system ID. I believe nfs will use the 1st instance (in your case it’s mounting /images rather than your new share /images2.

Edit the /etc/exports file.

For your /images and /images/dev lines, prepend them with a # symbol. This will comment those lines.

That, or change the fsid of the /images2 and /images2/dev to have 2 and 3 respectively.

Then restart the nfs service, systemctl restart nfsd

@Sebastian-Roth everything I’ve found on this issue refers to using the disks uuid to identify which one to apply it to. That doesn’t help us much as every drive on a system would have its own uuid. So how do we identify which is which? I know it doesn’t help anything. Everything from Serial to Pata and nvme aren’t guaranteed to be a persistent naming scheme for Linux. Luckily SATA and PATA seem to follow the channel pattern on how they’re connected and named. With NVME being on a pcie channel this makes enumeration dependent on how fast a disk feels like revealing itself to the system.

I know I seem distant and all these days, but this really sounds like a 4K advanced disk problem.

What makes me say this?

The nvme was a 512gb disk, I assume and it’s just a guesstimate. The sata disk is also a 512gb disk, guesstimate.

But look at the layout variances in reported disk size. One shows as about 465GB (sda) while the nvme shows at 477GB (nvme).

The oversized for each partition would seem, too me, to come from calculating disk sectors at a larger size than the actual disk can use.

I very well could be wrong of course and welcome any suggestions.

@sebastian-Roth I think we need to try figuring out a suitable mechanism to upscale to 4K only (less needed as most advanced disks will allow reappropiation of the sectors into 512B) as well as downscale 4K back to 512B. I don’t know of a good approach to do such a thing yet but it seems more and more people are looking to image cross spectrum.

@Sebastian-Roth I think it’s worth it. I can’t imagine a scenario where you’d be putting an image on an iscsi target.

@nehsa said in Create scheduledtask via POST to API:

“minute”: “30”,
“hour”: “5”,
“dayOfMonth”: “",
“month”: "”,
“dayOfWeek”: “*”,

This all depends on the type of task this is to do:

The json elements that you can set:

{
    "name": 'Some Name',  // Optional
    "description": 'Some Description', // Optional
    "type": "C", // C = Cron, S = Single
    "taskType": 1, // ID of the task type, 1 = deploy, 2 = capture, 3 = debug do not use this one, 4 = memtest, 5 = test disk, 6 = disk surface test, 7 = recover, 8 = multicast, 10 = inventory, 11 = password reset, 12 = all snapins, 13 = single snapin, 14 = wake up, 15 = debug deploy, 16 = debug capture, 17 = deploy no snapins, 18 = fast wipe, 19 = normal wipe, 20 = full wipe
    "minute": 30,
    "hour": 5,
    "dayOfMonth": '*',
    "month": '*',
    "dayOfWeek": '*',
    "isGroupTask": 0, // 0 = host only, 1 = group task
    "hostID": 1, // If is grouptask is 1 this will be the group id, otherwise the relevant hostID
    "shutdown": 0, // 0 = restart, 1 = shutdown
    "other1": "",
    "other2": "-1", // Snapins either the id of the individual snapin, or -1 for all.
    "other3": "fog", // The username who created the task
    "other4": true, // Wake On Lan?
    "other5": "",
    "scheduleTime": "", // Only used for delayed time in which case you will need a valid unix timestamp in the future.
    "isActive": 1, // 0 or false would mean the task is not active currently.
    "imageID": 1 // The image ID in the case it's an imaging task. Can be any imageID you want.
}

@Critchleyb

1.5.X and even 1.6.X are based on bootstrap. Some of the elements for fine tuning are defined in the default/fog.css file, but majority of the items are generic and using the bootstrap information directly.

If you need to customize particular things, and you know the class/ids you need to modify, you’ll want to edit the default/fog.css (though for your own environment I’d recommend creating your own custom something like critchleyb/fog.css and make your changes there.

@MarkG Apple may not have a GUI interface to display the hardware IDs.

http://teczd.com/2015/09/23/osx-get-system-info-from-command-line/

In particular: SPNVMeDataType