The files is not moved out of the dev folder and into its own folder. This was not a problem before I moved the /images folder into the /home folder. I have to do some more research tomorrow.

[quote=“Junkhacker, post: 31972, member: 21583”]update to 1.1.2[/quote]

AH okay, planning to do that later this afternoon.
Thanks for answering so many of my questions Junkhacker, its been a lot of help.

Many Thanks Tom

I had this problem when first setting up my server and I recall reading somewhere that when syspreping a machine, getting it ready for an image upload, it cannot be joined to the domain.
It has to be in a workgroup before running sysprep and uploading the image.
Since I started doing that, and making sure I entered my password correctly into FogCrypt, I haven’t had any problems with computers joining the domain.

Is this still true?

That’s a bit of a shame because it was neat to have it at your fingertips, ready to go on any machine, without having to install anything. But I also understand the downside of having to support it, code it into the web UI, etc.

Thanks for the help and for the information,
D.L.

I took the info here

[url]http://www.fogproject.org/wiki/index.php?title=WOL_Forwarding[/url] # WoL_Forwarding

It probably is.

I just realized one of my storage nodes were removed. Problem solved! I would delete the thread but I don’t see the option.

I didn’t realize FOG provided an uninstall guide :O, thanks!

I had this issue when trying to use Ubuntu 14.04 and I used 12.04 instead and have not had any issues since.

This is a known issue with FOG 0.32.

Open up the tasks.confirm.include.php file and replace all instances of &$tmp to $tmp.

The ISD services is started if that matters and I can force it to start from a command prompt.
Nothing pops up but I’ll take another look at it again today.

Thanks

EDIT: Not sure what the deal was before but I repackaged the snapin exactly like it was before and re-uploaded it with a different name and it’s working exactly like it’s supposed to now

I added correctly [CODE]date.timezone = “Europe/Athens”[/CODE], restarted apache and pc but nothing has changed:
Time here 11:00
in pc:
localtime: 11:00
bios time: 8:00
Log viewer/Schedulerer:
8:00…
I find strange:
time here 11:00
in pc:
localtime: 14:00 (which is wrong)
bios time: 11:00
Log viewer/Schedulerer: 8:00
I thought that Log viewer/Schedulerer: 8:00 was utc but in 2nd case it is not.
With or without [CODE]date.timezone = “Europe/Athens”[/CODE] the above are the same.
In the 1st case I can schedule correctly when I put scheduled tasks in bios time.
Why does this happen? I never had time problems…
Linux is debian 7.5 and fog 1.1.2. With xubuntu 14.04 happens exactly the same. With debian 7.5 with 1.1.1 I did not have any time problems.
Is it something related to fog 1.1.2 or some wrong setting in my pc?

[CODE]# cat /etc/timezone
Europe/Athens

hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1404124210 seconds after 1969
Last calibration done at 1404124210 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick…
…got clock tick
Time read from Hardware Clock: 2014/06/30 08:42:35
Hw clock time : 2014/06/30 08:42:35 = 1404117755 seconds since 1969
Mon 30 Jun 2014 11:42:35 AM EEST -0.453762 seconds
[/CODE]

Axel12, thanks for pointing out the obvious to me. 🙂 I looked through the log and it turns out I had disabled the Auto Log Out module for the client service. (Evidently, that’s important…) I enabled all modules and, voila! Joined the domain. Thanks for the help.

you could try having a pfsense VM do your routing.

pfsense VM with 2 NICs, one NAT, one internal.
other VMs have internal NICs, pfsense can handle your DHCP easily enough.

I do this with bridged NIC instead of NAT… but might work.

if your serious, drop the wireless and get Ethernet.

On your storagenodes are all settings correct?

In their respective config.php/Config.class.php are they able to connect to the database properly? Are their paths correct on the server? Are the permissions for those paths correct?

Well Congratz lol!

Sorry… Found the problem. The /etc/network/interfaces file had the wrong dns-nameservers configuration so it was not resolving domain names.