Posts made by Tywyn

Tywyn

@george1421 said in Windows (Powershell) / Username=Computername:

@tywyn In your PS script, add a text literal to the computer name (to just change it slightly as a test) when you create the user account. See if that works. That test will give you an idea if the computer name and user name can be the same.

My tests said, that you cannot have the same names, when you use Powershell, but you can have he same names, when you use the UAC

Tywyn

@tom-elliott said in Windows (Powershell) / Username=Computername:

Pretty sure the computer names aren’t allowed to be the same as usernames. I don’t know why, I think it’s because of domain issues

When I add a user via the UAC with the same username as the computername it works fine (at least under Win 7 64bit. Did not try it with win 10 though)

Tywyn

@george1421 said in Windows (Powershell) / Username=Computername:

If you run this PS script outside of the context of a snapin (i.e. run it locally on the target computer by hand) does it run correctly? Right now we need to isolate the issue. Is it a FOG Snapin issue vs a PS script issue.

Same thing, when I run it locally. I think, it is a Powershell/Windows-Issue

Tywyn

Hi there,

we are using Powershell snapins add local users after cloning.

I read the computername in the powershell-script and a user is added (New-LocalUser) with a username same as computername.
Then I add that user to the local group “Users” (Add-LocalGroupMember)

The user is created, but it is not added to the group “Users”.

This worked fine in Windows 7 32 bit, but not anymore with win7 64 bit and win 10 64 bit.

When username and computername differs, everything is fine.

And idea?

Thanx for your help
Rainer

Tywyn

@lemeunier
It seems, that your picture is not attached properly.

Tywyn

@Wayne-Workman , @Tom-Elliott Thank you gentlemen for your help. Truncating the tables was the solution.

@Tom-Elliott You said, that you see just one task. What does the Tasks: 4 (limit: 4915) mean?

Tywyn

Version 1.4.4
Debian 9.0.0

Hi there,

we successfully imaged some computers using multicast, but now it does not work anymore. I added 5 computers to a install group and asked to deploy via multicast.

Multicastmanager seems to be running:

# systemctl status FOGMulticastManager -l
● FOGMulticastManager.service - FOGMulticastManager
   Loaded: loaded (/lib/systemd/system/FOGMulticastManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-09-25 13:35:31 CEST; 2min 57s ago
 Main PID: 31574 (FOGMulticastMan)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/FOGMulticastManager.service
           ├─31574 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager &
           ├─31575 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager &
           ├─31967 sh -c /usr/local/sbin/udp-sender --interface ens33 --min-receivers 5 --max-wait 600 --portbase 54196 --full-duplex --ttl 32 --nokb
           └─31971 /usr/local/sbin/udp-sender --interface ens33 --min-receivers 5 --max-wait 600 --portbase 54196 --full-duplex --ttl 32 --nokbd --no

Sep 25 13:35:31 debian-linux systemd[1]: Started FOGMulticastManager.

Question for me is now: Before starting this multicast session with 5 hosts, I saw just: Tasks: 2. Why are there 4 now? And when there were 2: I have had no active tasks in the tasklist.

FOG Configuration Page->Log Viewer-> Multicast just shows:

[09-25-17 1:39:53 pm] | Task (16) Multi-Cast Task is already running with pid: 31967.
[09-25-17 1:40:03 pm] | Task (16) Multi-Cast Task is already running with pid: 31967.
[09-25-17 1:40:13 pm] | Task (16) Multi-Cast Task is already running with pid: 31967.

The 5 clients simply stop at the Partclone Screen, where it says: Starting to restore… and the Image location is …

Any help is appreciated!

Tywyn

Server

FOG Version: 1.4.4
OS: Debian 9.0.0

Client

Service Version:
OS:

Description

Hi there,

continued to register our hosts at our fog-server. After saying “Perform full registration” I get the following picture, before I can enter the hostname:

Bild Text

Usually I don’t get those messages, except the one “creating epoll fd”.
Here is the inventory-info of one of the machines.
Registred 7 of them by now, and all are giving the same messages, but registration works, as it seems.

Hope it helps. If there are any questions or any additional info I can provide: I am out of office until next monday -> then

Cheers, Rainer

System Manufacturer FUJITSU
System Product ESPRIMO_P556
System Version
System Serial Number YM4X051561
System Type Type: Mini Tower
BIOS Vendor FUJITSU // American Megatrends Inc.
BIOS Version V5.0.0.11 R1.11.0 for D3400-A1x
BIOS Date 02/02/2016
Motherboard Manufacturer FUJITSU
Motherboard Product Name D3400-A1
Motherboard Version S26361-D3400-A1
Motherboard Serial Number 49634444
Motherboard Asset Tag
CPU Manufacturer Intel Corporation
CPU Version Intel Core i5-6400 CPU @ 2.70GHz
CPU Normal Speed Current Speed: 3100 MHz
CPU Max Speed Max Speed: 8300 MHz
Memory 3.73 GiB
Hard Disk Model TOSHIBA DT01ACA050
Hard Disk Firmware MS1OA7J0
Hard Disk Serial Number 36583Y2AS
Chassis Manufacturer FUJITSU
Chassis Version
Chassis Serial YM4X051561
Chassis Asset

Tywyn

@Wayne-Workman, @george1421 Thank you, gentlemen. It was indeed a portfast issue. Enabling portfast on the specific switches solved the problem.
Btw: Your hint to put a dump hub/switch between client and network dose did solve the problem as well.

Tywyn

Hi there,

I have a strange behaviour here trying to register some hosts.

Assume I have Room1 and Room2 and ComputerA is in Room1.
Trying to pxe-boot fails, because ComputerA in Room1 does not see the dhcp-server. I also do not see the MAC-Adress in the /var/log/daemon.log.
Taking ComputerA to Room2, PXE works fine, registration also and also dhcp-log shows ComputerA.
Taking ComputerA back to Room1: PXE-Boot still fails, but when I start Windows and configure network to use dhcp I immediately get an ip-address from the dhcp.

Same Computer on PXE boot gets an IP in Room2, but not in Room1 but it gets an ip via dhcp when windows is running in Room1.

Any ideas?

Thanx in advance
Rainer

Tywyn

@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

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

select hostName,hmMAC from hosts left join hostMAC on hosts.hostID=hostMAC.hmHostID;

Hi George,

thank you for the hint with the NAC-Systems. Sounds very interessting but also like big pile of work, if you want to implement this
Also thanx for the SQL-statement. Works fine!!

The only thing that I am not sure about. When I look at the list of hosts and mac-addresses, there are two hosts, which have 2 mac-addresses: R222DOZENT and R222TN19.

R222DOZENT 00:25:11:xx:xx:xx
R222DOZENT 08:00:27:xx:xx:xx
[...]
R222TN01 00:25:11:xx:xx:xx
R222TN02 00:25:11:xx:xx:xx
[...]
R222TN19 00:25:11:xx:xx:xx
R222TN19 02:00:4c:xx:xx:xx
R222TN20 00:25:11:xx:xx:xx
[...]

Strange thing is also, what the second MAC-Address looks like: Usually we have macs starting with 00:25:11 and now I see 08:00:27:xx:xx:xx and 02:00:4c:xx:xx:xx

Cheers, Rainer

Tywyn

Hi everybody,

so far, no dhcpd had been in use at the place where I work at the moment. The reason is, that the IT-guys over here do not want anybody to be able, to just plug in their own notebooks into a network-dose (right word?) and the be able to surf in the internet.
Since we are willing to roll out fog for all 450 computers we operate, we have to find out, how to resolve this issue, because I think, fog needs dhcp and manually handling all the IP-addresses is not the most elegant way.

My idea was to use the isc-dhcp-server, which was configured by the fog-installer.

There I would define a block of dhcp-IP-addresses which shall be used for fog-operations, where the clients to not get a gateway (so they cannot go to the internet at this point, but can conenct to the fog-server).
And I would define a block of dhcp-IP-addresses, where an internet-gateway is provided. But within this block I would use a deny unknown-clients; statement.

My questions now are:

Is there another (perhaps more elegant) way to do this?
How do I get the mac-addresses of the hosts, which have already been registrered to the fog server into the dhcpd.conf (Or another file which I can include in the dhcpd.conf)?
Of course I could do a comp-paste thing, but there will be too many errors within time.
Where are the hosts, which are registred to fog, stored? Do I have to write an SQL-script, that accesses the fog-db or are there other tools to get this list automatically?

Thanx in advance
Cheers

Rainer

Tywyn

Ok … reran the install-script again, and now it seems to work.
Although it is very slow. Before we needed 15 minutes for the clients, now 45 are estimated.

Edit: Maybe the other switch only can do 100 MBit/s. Would explain, why it is so slow. Clients do 1,5 GB/min at the moment.

Tywyn

Server

FOG Version: 1.4.4
OS: debian 9.0.0

Client

Service Version:
OS:

Description

Hi everybody,

we have had 2 interfaces for our fog-server before. Call them inner and outer Interface. The fog-server listened to the inner interface before and now we decided to make it one network, so the inner interface isn’t used anymore. So we changed the IP-Address of the fog server.
Now everything seems to work fine with the outer interface (deploy one client, dhcpd, etc.) except, that we cannot deploy more than one client with multicast anymore.
Both Testclients stop with this message:

Partclone v0.2.89 http://partclone.org
Starting to restore system image (-) to device (/dev/sda1)
Note: Storage Location 10.203.8.21/images. Image Name M2_Win7

Storage location is correct.

Strange thing is, why a normal deploy works correctly, but not multicast.

First I thought, that it was maybe because of the different switch the outer interface was on now, but then I used the same switch as before (the switch, where the inner interface was connected before - clients are also on this switch), and it still doesn’t work.

What I can see in daemon.log:

Aug  2 10:07:35 debian-linux dhcpd[17694]: DHCPREQUEST for 10.203.12.2 (10.203.8.31) from 00:25:11:5e:65:b9 via ens33
Aug  2 10:07:35 debian-linux dhcpd[17694]: DHCPACK on 10.203.12.2 to 00:25:11:5e:65:b9 via ens33
Aug  2 10:07:35 debian-linux rpc.mountd[622]: authenticated mount request from 10.203.12.2:769 for /images (/images)
Aug  2 10:07:35 debian-linux rpc.mountd[622]: authenticated mount request from 10.203.12.2:851 for /images (/images)
Aug  2 10:07:36 debian-linux dhcpd[17694]: reuse_lease: lease age 3712 (secs) under 25% threshold, reply with unaltered, existing lease for 10.203.12.3
Aug  2 10:07:36 debian-linux dhcpd[17694]: DHCPDISCOVER from 00:25:11:5e:69:c5 via ens33
Aug  2 10:07:36 debian-linux dhcpd[17694]: DHCPOFFER on 10.203.12.3 to 00:25:11:5e:69:c5 via ens33
Aug  2 10:07:36 debian-linux dhcpd[17694]: reuse_lease: lease age 3712 (secs) under 25% threshold, reply with unaltered, existing lease for 10.203.12.3
Aug  2 10:07:36 debian-linux dhcpd[17694]: DHCPREQUEST for 10.203.12.3 (10.203.8.31) from 00:25:11:5e:69:c5 via ens33
Aug  2 10:07:36 debian-linux dhcpd[17694]: DHCPACK on 10.203.12.3 to 00:25:11:5e:69:c5 via ens33
Aug  2 10:07:36 debian-linux rpc.mountd[622]: authenticated mount request from 10.203.12.3:950 for /images (/images)
Aug  2 10:07:37 debian-linux rpc.mountd[622]: authenticated mount request from 10.203.12.3:823 for /images (/images)

So obviously the clients mount the image share.

Is there another logfile, where I can get more information?

Thanx,
Rainer

Tywyn

@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

Tywyn

Server

FOG Version: 1.4.4
OS: debian 9.0.0

Client

Service Version:
OS:

Description

Hi there,

I wanted to change the IP-Address of the fog-server (according to this guide: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address.

The installer fails at the dhcpd:

 * Press [Enter] key when database is updated/installed.

 * Setting up storage..........................................OK
 * Setting up and starting DHCP Server.........................Failed!

The point is, that obviously the dhcpd tries to bind to 192.168.100.x at enp3s1, which is the old IP-address/ethernet-interface.

The new one is 10.203.8.31 at ens33, which is in /opt/fog/.fogsettings, as well as in /etc/dhcp/dhcpd.conf.

The status of the daemon:

# service isc-dhcp-server status
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2017-08-01 13:35:37 CEST; 2min 0s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 8126 ExecStop=/etc/init.d/isc-dhcp-server stop (code=exited, status=0/SUCCESS)
  Process: 8234 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)

Aug 01 13:35:35 debian-linux systemd[1]: Starting LSB: DHCP server...
Aug 01 13:35:35 debian-linux isc-dhcp-server[8234]: Launching IPv4 server only.
Aug 01 13:35:35 debian-linux dhcpd[8245]: Wrote 0 class decls to leases file.
Aug 01 13:35:35 debian-linux dhcpd[8245]: Wrote 0 leases to leases file.
Aug 01 13:35:37 debian-linux isc-dhcp-server[8234]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
Aug 01 13:35:37 debian-linux isc-dhcp-server[8234]:  failed!
Aug 01 13:35:37 debian-linux systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Aug 01 13:35:37 debian-linux systemd[1]: Failed to start LSB: DHCP server.
Aug 01 13:35:37 debian-linux systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Aug 01 13:35:37 debian-linux systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

And the daemon.log:

Aug  1 13:35:35 debian-linux isc-dhcp-server[8234]: Launching IPv4 server only.
Aug  1 13:35:35 debian-linux dhcpd[8245]: Wrote 0 class decls to leases file.
Aug  1 13:35:35 debian-linux dhcpd[8245]: Wrote 0 leases to leases file.
Aug  1 13:35:35 debian-linux dhcpd[8245]:
Aug  1 13:35:35 debian-linux dhcpd[8245]: No subnet declaration for enp3s1 (192.168.100.1).
Aug  1 13:35:35 debian-linux dhcpd[8245]: ** Ignoring requests on enp3s1.  If this is not what
Aug  1 13:35:35 debian-linux dhcpd[8245]:    you want, please write a subnet declaration
Aug  1 13:35:35 debian-linux dhcpd[8245]:    in your dhcpd.conf file for the network segment
Aug  1 13:35:35 debian-linux dhcpd[8245]:    to which interface enp3s1 is attached. **
Aug  1 13:35:35 debian-linux dhcpd[8245]:
Aug  1 13:35:35 debian-linux dhcpd[8245]:
Aug  1 13:35:35 debian-linux dhcpd[8245]: Not configured to listen on any interfaces!
Aug  1 13:35:35 debian-linux dhcpd[8245]:
Aug  1 13:35:35 debian-linux dhcpd[8245]: If you think you have received this message due to a bug rather
Aug  1 13:35:35 debian-linux dhcpd[8245]: than a configuration issue please read the section on submitting
Aug  1 13:35:35 debian-linux dhcpd[8245]: bugs on either our web page at www.isc.org or in the README file
Aug  1 13:35:35 debian-linux dhcpd[8245]: before submitting a bug.  These pages explain the proper
Aug  1 13:35:35 debian-linux dhcpd[8245]: process and the information we find helpful for debugging..

dhcpd.conf:

subnet 10.203.8.0 netmask 255.255.248.0{
    option subnet-mask 255.255.248.0;
    range dynamic-bootp 10.203.12.1 10.203.15.254;
    default-lease-time 21600;
    max-lease-time 43200;
    option routers 10.203.8.31;
    option domain-name-servers 10.203.8.31;
    next-server 10.203.8.31;

.fogsettings:

ipaddress='10.203.8.31'
copybackold='0'
interface='ens33'
submask='255.255.248.0'
routeraddress='10.203.8.31'
plainrouter=''
dnsaddress='10.203.8.31'
username='fog'
password="someencryptedpasswd"
osid='2'
osname='Debian'
dodhcp='y'
bldhcp='1'
dhcpd='isc-dhcp-server'
blexports='1'
installtype='N'
snmysqluser='root'
snmysqlpass=''
snmysqlhost='localhost'
installlang='0'
storageLocation='/images'
fogupdateloaded=1
docroot='/var/www/html/'
webroot='/fog/'
caCreated='yes'
startrange='10.203.12.1'
endrange='10.203.15.254'
bootfilename='undionly.kpxe'
...

Any help is appreciated
Thanx, Rainer

Tywyn

@Sebastian-Roth said in Powershell-Snapin:

@Tywyn Probably just wrap another script around yours that does the call .\myscript.ps1 > C:\somelogfile.txt… Though I am not a windows guy but this might work.

Will try. Thanx!

Tywyn

The script runs and it does what it shall do.
The only thing is, that I would like to have the output (which is generated by Write-Output statements) redirected to a file.
When you execute a script from the commandline I usually did a .\myscript.ps1 > C:\somelogfile.txt which worksgood.

I was wondering, whether this can be done also with the script that runs as a snapin.

Thanx
Rainer

EDIT: The issue, why on client2 the script was not running is solved. client2 was in another network an thus not reachable from the fog server.

Tywyn

Server

FOG Version: 1.4.4
OS: debian 9.0.0

Client

Service Version:
OS: Windows 7 32bit

Description

Hi everybody,

wrote a powershell snapin which adds a user, sets the workgroup of the client, activated windows license and so on.
Some questions:

I start it with -ExecutionPolicy Bypass -NoProfile -File
Is there any chance to capture the output of the powershell-Skript and redirect it to a file?
Tried to add > c:\ps_out.txt which does not work.
I created a group, where I added 2 clients. I started the snapin on the group and client1 ran the powershell-commands and client2 did not start to do so. In the Task-Management I still see both clients: client1 says In-Progress (although done and already rebooted) and client2 says Queued, but does nothing (Think I found out why … not it the correct network to find the fog-server).
Why is client1 still listed in the Active Task-Overview? Is it possibly so, because after the script is run, the client cannot find the fog-server, because it is in a different network with new IP-Adress?

Thanks for your help
Rainer