Latest FOG 0.33b
-
Hostname changer: When the Hostname changer service module if ON, will a client change hostname during the last stage of Deplaying? Or is it necessary to run the FOG client on the client? I run 0.32 at the moment and several clients do not change name during deplayment on Windows 7. It seems quite random to me, which client change hostname and which does not. It this is a problem with 0.32, has it been improved in the 0.33 betas?
-
I haven’t tested quite that thoroughly, but it seems better in 0.33b yes. That said, do your systems join to a domain? If they do, the hostname changer service is what handles the joining as well as the hostname change. I don’t know what will make this work 100% of the time though as it’s done through registry keys. If you’re not sysprepping the machines I assume things should work perfectly fine, but if you’ve sysprepped an image, then it’s really up to the unattend.xml file for the rename.
-
Thanks. My systems do not join domain and I do not use Sysprep. Good to hear it problably works better in 0.33b. I will do some testing when I get time to set up a test server.
-
I’ll chime in on this one. I’m running 0.33b and I have the fog client already installed on the image that i’m pushing. Once the machine boots, the hostnamechanger module will check the FOG server to see what name is associated with the current MAC address that the client is installed on. So, as long as you have the host already set up in FOG server, the machine should just rename itself.
But, I went a little further. I have the machine sysprepped and joining my domain, which also works amazingly! Right now, my systems will image, reboot, go through oobe setup, reboot, rename, reboot, join domain, reboot, and finally install any snapins that I have for them. Automation is SO MUCH FUN! ! !
-
Lots of changes coming down. Legacy stuff is starting to be implemented. So if you upgrade from 32 to 33, all the images are still usable in some means. The GUI may not work perfectly, but it’s in place. It doesn’t work just yet as we have to add the properties to the init.xz. This is in the works though.
r1365 released fixes the LIST/SEARCH selections so they actually work.
-
r1368 released.
Fix boot menu for kernel checking. Add legacy update to service, if the image is uploaded. Update both init.xz
and init_32.xz for the new functions. Fix init’s for multicast legacy to perform the gunzip on the client. Update the config’s for buildroot. -
r1369 and r1370 released.
r1369:
Moves FOGImageReplicator service to a class file. Still need the initial script, but functions.php will soon not be needed at all! Much easier to manage. Purely uses Classes to get information.r1370:
Moves FOGMulticastManager service to a class file. Still need the inital script, but functiosn.php will soon not be needed at all!. Main difference is the looping has to be done internally. -
r1371 released.
Fixes a couple display issues. Fixes cron deployment issue in Group Page. Moves TaskScheduler into a class file. Please all enjoy.
Thank you,
-
r1372 and r1373 released.
r1372
Removes a couple unneeded files.r1373
Updates some documentation. -
r1374 released.
Just removes GreenFOG.class.php as nothing was using it. We still have GreenFog.class.php (notice caps.) Which I switched to using a while ago. Updates and add’s some more documentation.
The documentation stuff is just for me to keep track and update the documentation. I’m hosting the “documentation” and building it for doxygen. It can be viewed at:
[url]http://fogdoc.mastacontrola.com[/url] -
[quote=“Tom Elliott, post: 24479, member: 7271”]Well,
I’m going to be rewriting the FOG Service scripts over the weekend. It may not be fully complete but I am going to see what I can do to fix this. there’s no guarantee’s though okay?[/quote]
Hi, Tom
Could you look at the Service scripts this weekend ?
regards. -
I already did them. Why?
-
r1375 released.
Updates more documentation. Also updates the TomElliott.config files for 3.13.7.
-
[quote=“Tom Elliott, post: 24596, member: 7271”]I already did them. Why?[/quote]
So I can test the scheduled task with as master storage has external SAN like Synology ? -
Sure.
-
[quote=“Tom Elliott, post: 24602, member: 7271”]Sure.[/quote]
it works very well !!
-
[quote=“Tom Elliott, post: 24602, member: 7271”]Sure.[/quote]
I have just one last problem : as I said the SYNOLOGY or IOMEGA put before their NFS shares a name like “[B]volume1[/B]” or “[B]nethdd[/B]” while sharing the same FTP did not !
For the same share on SYNOLOGY:NFS : /volume1/imagesFTP : /imagesThe problem after the backup operation when ftp_delete and ftp_rename.
So I added before line 57 in / var/www/html/fog/service/Post_Stage2.php
[CODE]
// SYNOLOGY —
if(stripos($dest, ‘volume1’) !==false){
$src = str_replace(“/volume1/”, “/”, $src);
$dest = str_replace(“/volume1/”, “/”, $dest);
// IOMEGA —
if(stripos($dest, ‘nethdd’) !==false){
$src = str_replace(“/nethdd/”, “/”, $src);
$dest = str_replace(“/nethdd/”, “/”, $dest); }
[/CODE]
And replaced the function delete($path) in /var/www/html/fog/lib/fog/FOGFTP.class.php because SYNOLOGY do not like the “[B]ftp_nlist[/B]” function but rather “[B]ftp_rawlist[/B] "
[CODE]
public function delete($path)
{
if (!(@ftp_delete($this->link, $path)||@ftp_rmdir($this->link,$path)))
{
$filelistraw = $this->ftp_nlist_Syno($this->link,$path);
$filelist = (array_keys($filelistraw));
if ($filelist[0]){
foreach($filelist AS $file)
{
$this->delete($path.”/".$file);
}
$this->delete($path);
}
}
// Return
return $this;
}public function ftp_nlist_Syno($resource, $directory) { if (is_array($children = @ftp_rawlist($resource, $directory))) { $items = array(); foreach ($children as $child) { $chunks = preg_split("/\s+/", $child); //$item['type'] = $chunks[0]{0} === 'd' ? 'directory' : 'file'; array_splice($chunks, 0, 8); $items[implode(" ", $chunks)] = $item; } return $items; } // Throw exception or return false < up to you }[/CODE]
[COLOR=#3366ff]There he has a way to solve this problem ?[/COLOR]
[url=“/_imported_xf_attachments/0/610_Capture.JPG?:”]Capture.JPG[/url]
-
I didn’t design IOMEGA or SYNOLOGY NAS Systems. So it’s beyond me how and/or why you can’t use the true paths properly.
-
The problem is the FTP step (rename and delete) why not just do these steps in NFS ?
-
So what’s wrong with the FTP Step? If I understood your previous post, FTP to those directories removes the /volume1/ label and sets the home to /volume1/ making the ftp step look at /images through relative means. I didn’t configure there FTP server, so I don’t know how to help. The reason for not doing it via NFS is because of permissions.
