Posts made by Tom Elliott

Fixed thanks for reporting.

@Sebastian-Roth this can be addressed from the location plugin under the fog configuration. Location adds a fog setting for allowing snapins to be downloaded from the host location or the master storage node the snap in resides within.

@Sebastian-Roth nearly any web GUI account uses a default user and default password. I suppose we could ask the user what account they’d like to name it and assign a password at install time, this isn’t too hard. That said should this be a GUI and Local user or one or the other? Too many questions too think of.

What might help is detecting if the fog local user already exists, and if so present the user with the question asking what it’s password is set to. If the fog local user doesn’t already exist, create it and set using a random password. Should this also be what we set the GUI user for then? If so how do we ensure the user knows this password?

Just my ramblings but hopefully brings a little insight and or innovation?

@NT_Tech Access control is a plugin now which has much more use than the “mobile” vs “non-mobile” account.

FOG was indeed a single user system, from it’s original startup. The only thing that kind of made things different was the mobile interface.

I want you to understand, mobile interface was it’s OWN element from the main interface. This meant having to update two GUI platforms to ensure all functionality was maintained. When moved to a single interface that could do both mobile and full screen usages, I removed the “mobile only” user type.

I want to stress, while it wasn’t necessarily intuitive, even in 0.32 a “mobile only” user had exactly the same level of usage as the full admin users. The GUI access was limited and didn’t allow a mobile only user to see anything, but a mobile user could delete items, change things, etc… if they knew the url pathing and calls. They couldn’t see it, but it was not “limited” in the way you thought it was. As the access control plugin was created and managing a single interface made updating and keeping things in a more testable and common way, I decided to remove the “mobile only” option. This was not intended to hurt people who were using the element, but rather there were better things in place that did far better at controlling the scope of things and in a more granular and appropriate fashion.

@Sebastian-Roth Virtual users still require “physical” home drive locations.

I’ve used VSFTPD in virtual user mode and while it works and can be managed via mysql, it still requires physical access. Usually to a single user which new virtual user folders get generated.

Using the virtual user mode would mean we still have a local account, but with some robustness involved that allows us to limit access to specific virtual users.

I don’t know what method is better (one way or the other).

@arnaudrigole did you ensure to shutdown without fastboot switched on?

Don’t forget to ensure bitlocker is disabled. In the past even if you didn’t enable it specifically, bitlocker would encrypt the free space which could cause this type of issue as well.

I just tested using my api token for slack running the working-1.6 version of fog and am not seeing an issue.

What version of FOG are you referring too?

It’s possible the API has changed and this plugin is needing to be heavily revamped, but I don’t know for sure how to test especially without knowing what version of FOG you’re referring to.

@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).

Ubuntu, itself, hasn’t been an issue. It’s the liberties the Ubuntu team has decided to take in regards to security. They are certainly valid for taking those liberties with the exception of re-applying those liberties even after configuration has allowed the workaround. That’s about the only main thing I’ve seen with Ubuntu as the OS. And it only seems to be in regards to mysql, otherwise Ubuntu, Debian, CentOS, or RHEL are what I would suggest.

Arch is supported, but with every update available being applied pretty much as soon as they’re released, in a production environment I would not recommend Arch as the base OS. That’s not to say you couldn’t use it, just I would not recommend it.

If you’re looking for stable and ready long term support then I’d recommend either RHEL, CentOS or Debian (the OS, not the base.)

I know it’s been a while since I posted this announcement, but I’ve been kind of keeping up with @Sebastian-Roth with his code changes with 1.5.5 and how they apply to 1.6 as well.

Remember, for the most part, the backend side of FOG is staying the same with as minimal of changes as I can. What this means, is many of things in terms of overall performance and functionality that has been going into 1.5.5 can be relatively simple to apply to 1.6.

There are some caveats to this though. But I think things are looking much better than they had from the initial posting of this.

I know it’s the holiday season and I hope everybody enjoys it. I think this is all the more reason to apply the post so it can be viewed a little more readily.

Thank you all.

I’m not understanding your question. Or at least not understanding what you mean or are intended to obtain.

FOG, itself, knows nothing about your Drives used/free space. We use a block based imaging tool called partclone. Partclone can detect the used vs. free/empty space.

All Fog does is use utilities that are readily available to do all the work. FOG just automates the usage and mathematics of these things to help with resizing and expanding.

I’m sure this isn’t the answer your looking for, but to understand what I mean you’d have to look at the source code. https://github.com/fogproject/fos

Specifically the bin and usr/share/fog locations.
https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay

Most often this is not FOG related at all, rather a misconfiguration in your answer file. As to what, I don’t know.

What Windows are you using?

What else have you tried?

What version of fog. Most likely, as we stopped using sourceforge after 1.4, you have very old versions of the inits.

@salted_cashews I would highly recommend not setting the compression level higher than 19. 20 - 22 are considered ultra and require a TON of memory. Unless you’re not seeing a problem here, I suppose this could be partly why you’re seeing issues too.

Does the machine have the FOG Client installed on it?
What version of FOG are you using?

Here’s a couple of quick and dirty txt files containing all the hook events, and their respective tie-ins for plugins or hooks for operationally using them.

I’m posting this because the AccessControl plugins uses these very emphatically to help with granularly controlling access. This, ultimately, means a full documentation of all the things that can be done natively.

One file is the “Core” events. These are the events that can be enacted upon and integrated directly with the “base” of FOG using no plugins. The other file is all the hooks that plugins also generate.

My hope is to get the access control plugin more on a dynamic nature than a guessing game. In the past I had tried documenting all the hook events into the database, and while this approach can work, it only inserts new entries when the event is to be processed in the first place.

What’s wrong with the above approach? Well, to limit constant read/write to the database, the hooks were only inserted into the database as they were spawned. So let’s just say, for example, you never visited the User page. Your hookEvent’s table would never contain any of the hooks that are available on the user page.

In these files, particularly the core file, is some commonalities between all pages I think. This will be evident just by looking at these files. A couple of places, however, use a generic approach to generate the event. These are using a % symbol to symbolize Host, Group, User, etc…

Some of these will also function for the Plugins too (just a note).

Hopefully this will help prepare people with some of our changes for when 1.6 is able to be published.

Hooks_And_Tie-ins.txt

Hooks_And_Tie-ins - Plugins.txt

Please make sure the image has an associated storage group.

You can’t, the 2 is the Id as it sits in the database.