(place holder)

@Prostate14 I can help you get started with the USB key. Look at the forum chat (bubble at top of forum page) for additional hints.

Another quick command you can run from a linux command shell would be

showmount -e localhost

That should show you the nfs shares currently enabled. If the /images share is available, then check into directory file ownership and permissions.

@Sebastian-Roth The only thing I can think is that iPXE is not that smart to support 802.3az protocol but the 4.x linux kernel drivers are. That may explain while the older linux kernels worked on this box (because they did not support this feature).

Well my first round of tests have failed, but also did add some light onto what I suspected. The storage node needs a web server running because the master storage node makes some calls to the storage node for image deployment. The following is a call I trapped on the IIS server.

/fog/management/index.php node=client&sub=wakeEmUp&mac=00:50:56:94:f5:21

and

/fog/status/getimages.php path=%2Fimages

At this time I don’t think the windows server (or a synology nas) will function as a storage node out of the box. I could load apache or the php plugin for IIS and get it to work. But I’m not sure if its worth the effort.

I can setup nfs on windows, I can setup ftp and the images will replicate to the windows server. But without php and the rest of the storage node code, I’m at a standstill.

As it stands now, this post https://wiki.fogproject.org/wiki/index.php/Windows_Storage_Node will not work either and should be deprecated.

Your version of FOG is old, but that should not cause this error. You say you have a new macbook, what year is it made? After a certain year the macbooks use the T2 chip for security. This T2 chip needs a special FOS Linux kernel to access the hard drive.

What does the content of /images/<image_name> look like? Can you provide a picture of the contents of that directory?

I don’t know mac os but is it possible that mac os version 10.12 does not support the hardware on this new macbook, where the new macboon needs 10.15 to work correctly?

I guess I have to just throw this out since you are starting with a new deployment.

Is there any thought of changing your OS from Ubuntu to Centos? In my test environment I’ve spun up about 10 - Centos 6.7 systems with FOG in the last 2 weeks and deployed all of the trunk images without any deployment issues. In monitoring this forum for the last few weeks the majority of the install issues appear to be with the Debian based systems. I’m not saying that one OS is better than the other, but if the goal is to test FOG, then switch OS for the test and work out the kinks with the specific OS deployment later.

I have both centos 6 and 7 I can test one give me a minute to finish my first cup of coffee.

Tom added some new code checks (30-Mar-16) that will have FOG revert back to the 1.2.0 way of checking for images if the storage node doesn’t respond properly to the http query. This opens the door again to proving if a windows storage node is possible.

@zyzhang I did not see the year of the macbook you are talking about. If its a new macbook made after 2018 (guess) it uses the T2 security chip to protect the information on the hard drive. This T2 chip causes a problem with the normal linux kernel. I have a kernel patched by me (not the developers) that might support the T2 chip for imaging. You can test this one-off (special) kernel by downloading the bzImageT2 kernel from this link: https://drive.google.com/file/d/10j8fZ3i3Y_uICxcMgX5lpiuQ2ci9bCJG/view?usp=sharing

Download that file and copy it to the usb boot disk replacing bzImage with bzImageT2. Be sure to rename bzImageT2 to bzImage so your usb drive will boot using this one-off kernel. Understand this kernel is not supported by the developers since it was not officially released by the fog project developers.

This is more of a discussion than a help request.

We had an issue where we ran out of disk space on one of our test environment FOG servers. The problem started when we uploaded more host images than we had space on the FOG server. Searching the FOG server we saw that the host images are stored in /images and the snapins are stored in /opt/fog/snapins. Both of these folders exist on the root file system. Coming from old school unix we would typically create the /opt and /home not on the root file system because these directories typically grow the most. And on the older unix file systems if you fill the file system the OS crashes very badly.

(note for any of this thread to be understandable you need to read from the bottom of this thread to the top since the later posts appear first)

While this is a bit off point, I did find the issue with my script.

Win7
/ntfs/Windows/System32/sysprep (folder)

Does not equal

Win10
/ntfs/Windows/System32/Sysprep (folder).

Ugh case sensitive paths and windows consistencies.

Part 1b

Here is a rough outline on how to do this same thing with Windows 2008 R2. I hope to be able to test this as soon as I get my test environment rebuilt.

The following executed correctly on Windows 2008 R2 with Windows Managment Framework installed which installs PowerShell 3.0 I’m actually not using very many powershell commands here, basically just to add windows roles and features. Powershell on Windows 2008 is a bit lacking as compared to 2012.

Set-ExecutionPolicy Unrestricted -Scope CurrentUser
Import-Module ServerManager

Add-WindowsFeature FS-FileServer
Add-WindowsFeature FS-NFS-Services

mkdir c:\share
mkdir c:\share\tftpboot
mkdir c:\share\images
mkdir c:\share\snapins
mkdir c:\share\snapins\ssl

net localgroup fog_users /add
net user fog_user "mi5ty_cl0ud" /add /EXPIRES:NEVER /PASSWORDCHG:NO /active:YES /Y
net localgroup fog_users fog_user /add
icacls c:\share /grant "fog_users:M"

*****

nfsshare images=c:\share\images -o rw sec=sys root unmapped=yes
netsh advfirewall firewall set rule group="Server for NFS" new enable=Yes

*************

On FOG server
mount -t nfs 192.168.1.205:/images /mnt
mkdir /mnt/dev
touch /mnt/.mntcheck
touch /mnt/dev/.mntcheck
umount /mnt

****************

# On windows server
Add-WindowsFeature Web-WebServer,Web-Common-Http,Web-FTP-Server,Web-FTP-Service,Web-FTP-Ext,Web-Mgmt-Console

Import-Module WebAdministration
New-WebFtpSite -Name "FOGFtpSite" -Port 21 -PhysicalPath "c:\share" -IPAddress "192.168.1.205" 

Set-ItemProperty "IIS:\Sites\FOGFtpSite" -Name ftpServer.security.ssl.controlChannelPolicy -Value 0
Set-ItemProperty "IIS:\Sites\FOGFtpSite" -Name ftpServer.security.ssl.dataChannelPolicy -Value 0
Set-ItemProperty "IIS:\Sites\FOGFtpSite" -Name ftpServer.security.authentication.basicAuthentication.enabled -Value $true
Set-ItemProperty "IIS:\Sites\FOGFtpSite" -Name ftpserver.userisolation.mode -Value 4
Add-WebConfiguration "/system.ftpServer/security/authorization" -value @{accessType="Allow";roles="fog_users";permissions="Read,Write";users=""} -PSPath IIS:\ -location "FOGFtpSite"
Restart-WebItem "IIS:\Sites\FOGFtpSite"

*********************************

New-Item "IIS:\Sites\Default Web Site\fog" -type Directory
New-Item "IIS:\Sites\Default Web Site\fog\service" -type Directory
New-Item "IIS:\Sites\Default Web Site\fog\service\ipxe" -type Directory

********************************

In IIS management for the default web site must update mime types to add “.*” (dot star without the quotes) and with a type of “application/octet-stream”

********************************

#Now that IIS is all setup and ready you will need to copy all of the files from /var/www/html/fog/service/ipxe to the IIS server in the windows path IIS:\Sites\Default Web Site\fog\services\ipxe
#Lets do this with nfs. Create the NFS share on the Windows server

nfsshare fogipxe=C:\inetpub\wwwroot\fog\service\ipxe -o rw sec=sys root unmapped=yes

****************

On FOG server
mount -t nfs 192.168.1.205:/fogipxe /mnt
cp /var/www/html/fog/service/ipxe/* /mnt
umount /mnt

****************

# On Windows server, remove the nfs share
nfsshare fogipxe /delete

(Note: you need to "replace all child objects permission with inheritable permissions from this object" on C:\inetpub\wwwroot\fog\service\ipxe or the bg download test will fail
# need to figure out the icacls command on this one

Install the TFTP service as outlined in the OP

I have a one-off kernel that seems to work for the MACs with the T2 chip.
https://drive.google.com/file/d/10j8fZ3i3Y_uICxcMgX5lpiuQ2ci9bCJG/view?usp=sharing

Download this kernel as bzImageT2 (watch your case) and save it on the FOG server in /var/www/html/fog/service/ipxe directory.

Manually register that computer on the fog server. Then in the host definitoin for this apple computer in the kernel field enter bzImageT2 and then pxe boot the target computer. That should address the issue with the T2 chip and allow FOG to see the disks below the T2 chip.

Now also understand that I know pxe booting the apples are a bit troubling at times. From your post it sounds like you have it worked out, but I know that some people find it easier to boot from a USB stick into FOG and skip the entire pxe booting process. We have a solution for that too.

MOD Note: This issue is not a FOG bug but a hardware limitation so I’m moving this thread to the mac problems forum.

I have a similar request to what I understand you want to do.

https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node

You can get pretty close by using the location plugin by installing a deployment fog server in each location. Then from a master deployment server you can move files to the site deployment server via the normal storage node replication. This is not a typical setup but I can get the images deployed to the sites this way. The only issue is getting the database entries from the master deployment server onto the site’s deployment server database. I can do this by scripting, but its not built into the logic as of yet.

@george1421

For clarity the command Tom provided didn’t return any value, but it did set me on the right path (so to speak).

Well its not as clean as I hoped, but this command will return what I want.
find /ntfs -type d -iname "sysprep"|grep ystem32

For what ever reason sysprep exists in System32 and SysWOW64. Either way the above command will return the proper case regardless of the target OS.

[edit] And this command will find the proper unattend.xml regardless of the case.
find /ntfs -type f -iname "unattend.xml"|grep ystem32
[/edit]

Part 2

For the remainder of this thread I’ll continue with the Windows 2008 R2 server as the windows storage node. If time permits I’ll circle back and attempt the same thing with 2012, but based on what I’ve done so far I have confidence that 2012 will work equally as well as 2008.

There is one bit of error data I found running through a QC check before moving onto the next part. I created the FTP site using the powershell command: New-WebFtpSite -Name "FOGFtpSite" -Port 21 -PhysicalPath "c:\share" -IPAddress "192.168.1.205" While testing I found that the -PhysicalPath switch did not update the ftp server setting causing the ftp server to report that the home folder could not be located. I went into the mmc console for IIS and manually set the homedrive for the ftp server. Once that was done I was able to login via FTP.

On to the QC checks before moving on to the FOG setup of this. For these tests we’ll use a windows 7 workstation.

First we need to test to see if the FTP server is working and we can login using the fog_user account we setup.

C:\>ftp 192.168.1.205
Connected to 192.168.1.205.
220 Microsoft FTP Service
User (192.168.1.205:(none)): fog_user
331 Password required for fog_user.
Password:
230 User logged in.

Just issue a dir command to see if we can see the files we created.

ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
05-22-16  08:39PM       <DIR>          images
05-22-16  07:41PM       <DIR>          snapins
05-24-16  02:42PM       <DIR>          tftpboot
226 Transfer complete.
ftp: 144 bytes received in 0.00Seconds 144000.00Kbytes/sec.
quit

That completes the FTP test

The next step is to test the tftp server

C:\>tftp 192.168.1.205 get default.ipxe
Transfer successful: 427 bytes in 1 second, 427 bytes/s

If your tests matches the above then we can move onto the FOG part of the setup.

My dev environment was created fresh with the latest trunk version of FOG 1.2.0. The following is the complete steps I went through to setup FOG to communicate with the windows storage node.

Fog Configuration -> Plugin System
FOG_PLUGINSYS_ENABLED = checked

Plugin Managment
Activate and install Location management plugin

Storage Management -> Add Storage node
Name: WinStoreNode
IP Address: 192.168.1.205
Web Root: /fog
Max Clients: 10
Is Master Node: (unchecked)
Replication Bandwidth: 0
Storage Group: default
Image Path: /images
FTP Path: /images
Snapin Path: /snapins
SSL Path: /snapins/ssl
Bitrate: (blank)
Interface: eth0
Is Enabled: (checked)
Is Graph enabled: (unchecked)
Managment Username: fog_user
Managment Password: mi5ty_cl0ud

Location Managment -> Create New Location
Location Name: winsn
Storage Group: Default
Storage Node: WinStoreNode
Use inits and kernels from this node: (checked)
Press the Add button

I next copied a host image from my production server to the dev environment. Once all of the files were in place, I went back to the FOG GUI and added an Image reference that defined the image I copied over from my production server.

And finally I restarted the FOGImageReplication service. Inspecting the /opt/fog/log directory you should see the replication service start up with a transfer log specifically for the windows storage node we just created (i.e. fogreplicator.log.transfer.WinStoreNode.log). If you see this long file, hop over to your windows storage node and inspect the directory c:\share\images to see if the image files have started to copy over from the FOG server.

@saftkartoffel said in Clear block out of boundary:

Well I got Fatal: error unknown request type :: Null
Got a quick fix? need to do the imaging asap

This is one of the caveats of usb booting. You should reread the instructions for building the FOS Linux USB boot disk. It says that you MUST schedule the task first in the Web UI THEN select option 1 on the grub boot menu. If you don’t you will get the error about Unknown request type Null.

I found this bug report for 14.04 of ubuntu.

https://bugs.launchpad.net/ubuntu/+source/php-apcu/+bug/1422484

In a nutshell the fix seems to be:

sudo apt-get purge php5-apcu
sudo service apache2 restart

Not a FOG issue more about ubuntu.

@Tom-Elliott said in (r7084) Login history - username searching doesn't work:

Confirmed, found, patched, fixed, tested, and pushed.

How many more words can i begin to use?

Done, Boom (mic drop)?