Topics created by Tywyn

Thanx! Will try!

Finally added the simple route of HTTP redirect via index.php (99a407e and ad2813ab).

Thanks to @Tywyn who provided the initial password I was able to figure out why this happened. The installer uses the password to update the storage node setting in a way that is prone to a URL encoding issue. I have to admit I didn’t know base64 encoding can actually produce strings that can cause such a problem:

$ echo -n 'as~ja$j2niau83j2' | base64 YXN+amEkajJuaWF1ODNqMg==

The + character is then miss-interpreted by the PHP code as space character and therefore breaking the base64 decoding of that string.

I just pushed a fix to dev-branch in hope if this fixing all cases that special characters could cause in that part of the code.

@Sebastian-Roth , @george1421

Thanx for your help.
I set up a new virtual host with ubuntu 18.04.03 LTS server with fog and dnsmasq and everything went fine for the installation part now.
The ubuntu 18.04.03 provides apparmor by default, so I assume, that apparmor was not the reason for the install-issues I had before.
Maybe the fact, that I have had mysql installed manually, tried installation of fog and removed mysql after noticing, that fog wants to install mariadb, gave us the troubles we had.

Now another problem arose, but I opened another thread for that: https://forums.fogproject.org/topic/14197/1-5-7-does-not-capture-correctly

@Sebastian-Roth & @george1421
Thank you for your help. Updated the kernel and inits the way you described it. Now the capture works.
Installed 1.5.4 on august 9th, as far as I can see.

Thanx.
The thread can be marked als solved. Can I do this somewhere or can just a board admin do that?

@Sebastian-Roth
Cannot replicate the issue at the moment either. But I did an upgrade from 1.5.2. to 1.5.4. in the mean time.
Maybe this fixed it.

Please close it. If it reoccurs, I will show up again.

@tywyn Glad you got it working. There’s been a whole lot of improvements around partitions and resizing in the last year, so it must be an issue with 1.4.4 in your case.

Thanks for your advice. Will try on monday.

@tywyn the largest difference is that SYSTEM is not allowed (by design) any interaction with the user or userspace at all. This probably also means the user’s account too. This is Microsoft’s design, not ours - and they went that route for security reasons.

When developing snapins, if your snapin will work manually but not as a fog snapin (and you’re sure you deployed the snapin correctly), you can normally assume the problem is because of the above.

Try what @Avaryan posted.

@Tywyn Great to hear you could make it work again. I have no idea what was wrong before. I have looked through the code many times and don’t know what could have gone wrong. Marking this solved now. Let us know if you see this again.

@x23piracy said in [Windows (Powershell) / Username=Computername]

@Tywyn like @Avaryan said why not use unattend.xml to create local users?

Having a Powershell-script, that does more, for example, set ip-addresses, active office/windows, sets the correct time, etc.

AND: I have no idea how to use unattend.xml 🙂

@tywyn That’s the “processes” (called tasks in systemctl) that are running for the service. Those, themselves, are not tasks in the sense as you’re referring to them.

@Tywyn As suggested try updating the machine’s firmware or disabling ACPI in the linux kernel. For the later add acpi=off as kernel parameter in the host’s settings and see if the messages are gone. As George already said, those messages shouldn’t be a show stopper.

@tywyn said in Computer does not see DHCP on PXE-Boot, but it does with Windows running:

Your hint to put a dump hub/switch between client and network dose did solve the problem as well.

FWIW: This is a quick test we can use to see if standard spanning tree is the issue. The dumb switch will keep the building switch from transitioning during the boot of FOS.

@george1421 said in dhcpd and known/registred hosts in fog:

select hostName,hmMAC,hmPrimary from hosts left join hostMAC on hosts.hostID=hostMAC.hmHostID where hostMAC.hmPrimary<>1;

Works perfect. Thank you again!
Cheers

Rainer

@Tywyn Probably there was the multicast interface setting (FOG web GUI -> FOG Settings) still wrong.

Not sure about the performance issue now. Please check layer one (hardware, switch) first.

@sebastian-roth said in Changed IP of Fog, dhcpd is not starting anymore...:

/etc/default/isc-dhcp-server

That was it.
I changed it, because indeed there was the old interface in there. Now the dhcpd works fine.
I also found, that in /tftpboot/default.ipxe was the old IP-Address.

Maybe these two places are worth to be mentioned in https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address

Now I have another problem, but I will open a new thread for this 🙂

Thanx everybody for your help!
Rainer

Tom has a good point here. I’ve struggled with launching powershell from the FOG Service with the correct privilege level to prevent UAC pop ups you never see. Disabling UAC on a PC and retrying the snapin will can be a good testing step. Windows 7 and Windows 10 treat UAC differently, or so it seems. To get around UAC in Win7. Seach for elevate.cmd and elevate.vbs that came out with Server 2008/Vista. I’ve found that this can successfully elevate a PS script in Win7. I’m still working on Win10.

if you’re actually getting powershell to start your script, you can also pipe the output to a file using the out-file cmdlet:

powershell.exe -Executionpolicy Bypass -noprofile -file myscript.ps1 | out-file full [full path to some text file]

Jim

@george1421 It is a physical machine with 1 onboard NIC and (now) one TP-Link networkcard.
Works fine now.

Thanx for the help!