@oelked I’m not sure I understand.

What is Persistent Groups plugin not doing that you’re hoping for?

Don’t get me wrong, a plugin building is a good time, as it helps you learn how to hook and event things in the FOG UI as well as potential interactions with other elements as possible. Just I don’t understand the scope of the problem you’re having that Persistent Groups couldn’t address.

Hello, no problem, I’ll try to describe it in more detail
Steps to reproduce

Create location

Set location name

-Storage Group
Establish

Storage Node
Omit because Node is not yet created or exists

Set Storage Node Protocol HTTP

Use inits and kernels from this node True

Add

no error occurs

Location is created.

When you create another location using the same procedure, the previous one will be overwritten
no new location will be created.

This behavior only occurs if no storage node is stored.

I noticed this behavior because I wanted to create my location structure in the master before I created all the storage nodes.

@Outer2211 Why is this a bug?

If the timezone isn’t defined (in the FOG Settings) it should default to the UTC time as it wouldn’t know what timezone your system is in.

@Tauric From the pictures we see that FOG recognized the filesystem as NTFS and should be able to resize it. It’s still strange the size was larger. Good you got this fixed by reinstalling the master to capture from. No idea what could have been wrong with the other one.

@Sebastian-Roth Thanks for the update! Again, this feature for us is more of a “nice to have” than an essential, so no immediate rush. I know all of y’all are busy!

@mronh I had a bit of time today and started looking at it. This is a bigger issue, code security involved and I wasn’t able to fix this in the time given.

I have got it on my list of things to fix when I find some more time.

@mosi This issue is fixed in the latest dev-branch version. Please update.

@AlexPDX This “bug” appears on new installs as well as on upgrades from any previous version.

This is just a minor thing because if things were right it would show the node’s kernel version instead of “Unauthorized”. It’s just not able to pull the kernel version information. Will be fixed when we find the time but this is not a show stopper.

@Mentaloid Confirmed a bug in 1.5.10. Will be fixed in the next version. Will keep you posted here.

Moving the topic to bug reports.

Code:
https://github.com/FOGProject/fogproject/blob/1.5.10/packages/web/lib/pages/snapinmanagementpage.class.php#L466
https://github.com/FOGProject/fogproject/blob/1.5.10/packages/web/lib/fog/storagenode.class.php#L200

@Sebastian-Roth Just an FYI, I ran into this again on different hardware. An HP Z2 G4 Workstation did the same thing.
There may have been more to it though, still troubleshooting a bit. My failsafe in the postdownload script to have it still join the domain through the unattend file was injected into the file, but the computer did not join the domain through that method, there may have been a different reason for that though.

Point being, there could be other hardware that weirdly doesn’t get all the variables. I sadly can’t super test on this hardware as I discovered it when imaging a production machine that I can’t take out of production for testing. But I can probably find a chance to get the fos level device info or something.

@pep Finally found some time to properly document this issue on github.

Update issue: https://github.com/FOGProject/fogproject/issues/561
Snapin issue: https://github.com/FOGProject/fogproject/issues/562

Both should be fixed in latest dev-banch. The later still needs some good testing. I just did a very basic test to make sure the default schema is being applied.

@Kleber I guess the spacing of the information printed is not working as intended when the status bar is just started. I played with the stuff a bit and came up with an easy solution that would expand the text information to the whole width but restrict the green status bar to the lower part:

statusbar.jpg

Would that be a feasible option? If not then some else with more status bar skill needs to look into this.

@premier Turns out this was a bug in the code. This is now fixed in latest dev-branch version. With the new official release on the door step your should update to 1.5.10 as soon as it’s out.

PS: If you’d kept up the topic and offered more information we might have been able to fix this way earlier.

Hi @Sebastian-Roth,
Yes, I think that the dev-branch solves the problem. I tried to install from master branch and the problem with the xinetd appeared, but with the dev-branch apparently works fine

I know this is quite an old topic, but we ran across this on the latest version of fog and I wanted to share my solution.

What ended up working for me was to get into the database console with mysql -u root

I then selected the fog database use fog;

Then I listed out the tasks SELECT * FROM scheduledTasks;

In my case the most recent record had an stID of 13, so I dropped that row, which fixed the issue DELETE FROM scheduledTasks where stID = 13;. After that the scheduled tasks menu loads fine.

@H3Krn Thanks for checking up in this. I’ve got it on my list but don’t seem to find the time.

@rodluz Do you want to take a look at this?

Thanks everyone for the comments on this. Looks like we better remove “Delete a host” and “Approve a Host” from the iPXE menu altogether.

With the “Update a product key” I see different opinions. While I understand your point @Tom-Elliott I am wondering if people actually use this at all because typing a 25 character key right at the machine is not much convenient. But on the other hand I think adding the security check should be enough to prevent from malicious/anonymous user inputs which @george1421 mentioned. I tend to leave that option in the menu but secure it - and same for “Join a multicast session”.

@skyrider223 I just merged your pull request and opened a new issue to take care of removing the menu items as discussed. I added a list of code changes needed to the issue report already. Are you keen to look into this as well?

@sebastian-roth Sorry, I didn’t see your answer. Yes it works.

@EduardoTSeoane And another old one I came across. This one is still an issue. I have dug through a lot of code today to try and properly fix this. While there are different ways of getting this right I didn’t want to mess with too much of the code and introduce new problems. In case anyone comes across this, feel free to look into it again and see if there is a better way.

Remove general encoding of HTML special chars (in FOGBase class) and add it where needed instead. This would be a lot of places (e.g. 1) because HTML output is generated throughout the code - so re-working pretty much all of that. As well this would also change the output we get from the API for example. Currently HTML encoded for no good reason I think. But changing that could break things for people being used to it. Another way would be to prevent the whole object from being saved in general when only associations should be set. This happens in many places as well (e.g. 2, 3). Same as above it would mean re-working a lot of the code. Although it’s probably worth it to reduce the amount of unnecessary changes being written to the database (improve performance a little). So I chose the simplest route of all to just fix this for snapins in dev-branch (4). It’s not perfect but at least the actual issue is fixed for snapins where chars like " and > are used by people. FOG still messes up those characters in other places, e.g. host/image description.

@EduardoTSeoane Just stumbled upon this topic. Got lost somehow…

I can’t replicate the issue as described in the latest dev-branch version (1.5.9.219 as of today).

I am pretty sure this was solved even before 1.5.9 was released: https://github.com/FOGProject/fogproject/commit/fffa0e2f3a1a0acab40670e53d1ffe054107b8c3