@arnaudrigole The message is clear, there is a Duplicate somewhere. We need you to search for it by searching for the MAC’s that @Joe-Schmitt gave you earlier.

You can even do a manual sql query if needed.

I’ve added the hostinfo.php script, though in a much different fashion. As I stated in chat and on the comments of the pull request, I have not added the setHostname due to security concerns. That all said, the information is now exposed as you requested.

@sebastian-roth et al.

Sorry, I’ve not been able much to work on anything in a while. I will try to correct that moving forward though I’m still fairly busy with work and all.

I’m keen, if everybody else is, to look over 1.6 vs 1.5.x and just simply moving over to it. The UI for 1.5 was itself quite an overhaul but shows too little progress now (that we’re at 1.5.9). Moving to 1.5.10 seems cursory at this point, in my opinion.

I can’t say I’ll have a lot of cycles free to keep this moving in a linear fashion though.

The biggest hurdles with 1.5.x and 1.6.x are getting the codebase ready with PHP 8 support it seems too me.

I’m of course able to try to help release a 1.5.10 release if that’s what’s really needed, but I think the 1.6 codebase has been around long enough and in parallel long enough it might be a good position to just check the bases, clean up where necessary, and release 1.6.0.

Let me know what you all think.

@Tom-Elliott https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

If you’re running the new FOG Client it will automatically register new hosts with whatever the hostname of the system is. Do not use Quick Registration to do this as all it does is make it so people don’t have to type anything and it’s purpose is to set the hostname.

I can try to look at a method of pulling the windows hostname out autonomously but this is more a feature request than a “problem”.

I think the new FOG Client installed on your systems would do better what you’re asking.

When the new client checks in, if host register is enabled, it creates the host entry into the FOG system under a “pending” status. This pending status should have the windows hostname as the hostname of the host within fog. All you would need to do is approve it.

Added as requested. This make sense to me. I’ve also added the total clients a Group can have.

@jacoboren As @george1421 pointed out, then I think what you’re looking for already exists.

FOG Configuration Page->FOG Settings->Plugin Settings-> Enable Plugins.

Go to the gear icon that becomes present.

Click on “LDAP” plugin (Looks like a key).

Go to install plugin.

Click on “LDAP” plugin.

Click on Install LDAP Plugin.

You will then have a new icon appear that looks like the Key in the main menu item.

Click there.

Create New.

Make the configuration as you need it.

@jgurka What you’re saying is wrong. I coded it, I know what it’s doing. I’m trying to help.

@jsmith if you go to the host and uncheck domain join and recheck it it will do the work for you.

FOG Mobile works perfectly fine.

I’ve been maintaining it, and even test it.

it isn’t as robust as the “main” page, but this is kind of the intent.

I’m not going to remove it simply because I think it’s highly useful when restricted to a phone.

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

@Wayne-Workman yes. This is because the Storage Nodes can also be responsible for the “Checking in/Completion” of tasks.

%WINDIR%\Panther\unattend.xml

@george1421 et all. I’m still around. I can probably help

@Sebastian-Roth LDAP used to store the bind password in encrypted form, similar to how we stored the ad default password in encrypted form. So there’s some back end work to verify if the password is in an encrypted form and if so, to decrypt it and pass it along. Otherwise just use the base text.

@Arrowhead-IT I’m aware of what the problem is, and it’s because I am forcing the directory of snapins to contain the ssl files.

In the code, particularly the decrypt code, I’m specifically searching the /opt/fog/snapins/ssl folder to do the decryption, or the global FOG_SNAPINDIR setting if it is set. Maybe this can help fix the problem? I will see about making an entry to allow for dynamic use and find of the ssl folder/files. For now, I’d recommend adjusting the global value. I’ll work on making it more dynamic and adjustable per node.

@lebrun78 https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Just for tracking purposes for those that would like to try this:

https://github.com/FOGProject/fogproject/tree/working-RC-11

Under packages/web/lib/plugins/ldap you will find the plugin.

Easiest way to get it would be to simply install the ldap plugin after installing working-RC-11 branch. I don’t recommend this only because while it’s a “WIP” and addresses bugs and minor improvements/fixes around what’s being found from RC-10, it’s also meaning those on RC-11 would be returning info that’s rather irrelevant for the time being. I’d prefer people to work on RC-10 and get a thorough list of bugs and issues to work out. That said, any of the developers and moderators that would like to install please do, I can fix the things I miss due to it not being in the “mainstream” of things which can help make RC-11 that much more suitable for environments.

This one exception (ldap) is the only thing I’d like to see people testing from RC-11 as it could use VAST amounts of improvements and make using FOG in an AD Environment that much easier to control.

For example, with the new modifications (once fully completed), you can define ldap authentication from eDirectory, openldap, ldap, and Active directory. You can associate groups in your ldap choice to allow users mobile access, and your IT team admin access. I hope something like SSO of this sort will make it into FOG 2.0 as well, which is why I’m kind of excited for this plugin to get revamped.

@Fernando-Gietz, @george1421, and myself have had the most authoring done for this plugin and have been added to the author’s of this plugin. @x23piracy You helped tremendously a few months ago with testing and providing an open test ring for me to use although it may not have accomplished what the two of us had hoped for.

Thank you @george1421 for actually kind of kickstarting this plugin back into shape. Thank you @Fernando-Gietz for actually establishing the basis of the plugin.

Anybody who would like to try this out so we can make it much better, please do and keep us posted. Please, for the time being, don’t post this into bugs though. I’m aware of the issues LDAP plugin currently has which is kind of why the work has been started to make it into a truly usable plugin.

I’ve seen this request but not quite sure how to move forward.

Please understand, Access controls, with this iteration of FOG Server, are coded after the fact.

What do I mean by this?

FOG didn’t really have any real security controls in place. You, indeed, needed to be logged in to do actions of course, but there weren’t any utilities in place for “modifying” access.

For a period of time, there was a thing called “mobile” user which basically just allowed a user to use a mobile interface. This interface was coded along side the FOG system, and was a cumbersome tool to maintain. So when we moved to a responsive design, I removed that “mobile” gui as the new GUI is also mobile accessible.

The Access control plugin is a huge leap toward getting a tool available to limit access based on rules/roles etc…, but it’s not a perfect system as it relies on the User existing in the database first.

I’m sure we could work to add a utility to enable a “default” role association but right now it doesn’t exist.

You’re absolutely correct. It’s chinese if it’s any help. It is not set until you set it, though I’m pretty sure I’ve made sure it defaults (now) to English.