@Fernando-Gietz While, theoretically possible, the password in the db is there as nothing more than a show. The password is not encrypted. It’s hashed, and a hash cannot be brought back to the password. You would have to brute force until you found a match and even then we are checking if the type is valid. So it IS possible, but very very unlikely.

@Wayne-Workman Thank you, sorry I missed this article when I looked for answers earlier.

@Wayne-Workman Thank you for taking the time to look into this, and I’ll just chalk it up to weird things that happens to me. Thank you for all your efforts and advise.

@george1421 said in pre and post image scripts:

Thank you very much for your replies. I think that the complexity of implementing this kind of security measure doesn’t worth the time. Perhaps just restricting access to several subnets is more than enough.
I will go that way.
Thanks!

yes I looked at fog transfert code too because I managed to connect glpi and fog but it’s not working further
and I’m not good enough with mysql to correct what’s wrong
anyway thanks for the tip of csv import

Nice! Thank you @Junkhacker and @george1421

I just changed it to work with the clients MAC address and it seems to work like a charm!

So now, i have this config:

iseq ${net0/mac} XX:XX:XX:XX:XX:XX && goto chainboot || goto fog.local :chainboot set pxeserver:ipv4 XXX.XX.XXX.XXX set next-server ${pxeserver} chain tftp://${pxeserver}/pxelinux.0 exit

I will do some testing but i am verry optimistic 😉

Thanks!

@andreas.paul said in Invoke hostinfo.php from powershell:

Im intrested in the option to query the database direct, do you have any snipped for this?

I’ve only done it with BASH, it’s easy in bash. Here’s an article about doing it in powershell. All I did was google-search “powershell query mysql” and there’s tons of results.
http://www.thomasmaurer.ch/2011/04/powershell-run-mysql-querys-with-powershell/

@Wayne-Workman you can make it a hyperlink: e.g. this thread

@Malos I must have been really under the weather when I escalated to the devs.

I actually know the answer. Currently the way replication works due to a bug in lftp concerning only replacing changed bits (remember that one @tom-elliott? ), If a change or difference is detected between the source file and destination file, the destination file is deleted and the copy is re-started.

@Joe-Schmitt I have no problem with that. Anything to help fog with

There is going to still be a “trunk” branch and I’ll still be doing (albeit much less than in the past) work on the PHP side of FOG, but really limited to bug fixes and minor improvements. I don’t expect any new features to be added unless it’s to support some new functionality in regards to the new FOG Client that we find useful enough to be added to the current channel’s of FOG.

As we get closer and closer to a functional element of FOG 2.0 (which will likely take a while) we’ll most likely give up postings to try to get our testers and other developers updated to test and report things.

I clicked edit on his post because sometimes the triple tics when done wrong hide text, and he did post a line of code, I fixed it so we can see it now.

But it still makes no sense to me. It looks like he’s trying to use VB.NET.

BASH is easier.

Awesome, that answers my question. Thank you!

I took a look at the code and I don’t remember why I added that. The same likely happens for “routeraddress” and “plainaddress” as well.

I’ve republished RC-15 to have the code changes in effect to correct the installer issues in regards to these four fields. I also re-tagged the RC-15 as RC.2 is just a tag, it’s not the “version” applied to the installation.

@Wayne-Workman I’m not saying you all are.

I’m saying how I might approach the situation from a personal mindset.

Just confirmed and sharing - FOG 1.3.0 RC-11 also works just fine on Fresh Ubuntu 16 Server without any special commands.

I feel I should add all Enabled nodes will send wol. Non enabled won’t cause they’re not enabled lol.

If you have a spare machine laying around, I’d ask you to try FOG 1.3.0 RC, and see how it goes. Leave your old fog server alone for this.

Bad HDDs don’t act uniformly. Just because an error was thrown in Clonezilla doesn’t mean the same one will be thrown in FOG, and vice-versa. Of course people on the forums here have posted pictures of very strange errors in partclone before, and of course those were sometimes due to bad HDDs.

My recommendation is to not assume an old drive is good. If it’s older, do a health-check on the drive before you ever start building your image on it. This should prevent a lot of problems.