@Piplup said in Proofread concept: I discarded the VLAN idea because it’s too late to implement safely now for me. You’re right - there is 1 L3 10 Gigabit Switch and A lot of L2 1 Gigabit Switches My question was, is a network as described with the network plan I provided realistic? I worried that because everything is in one LAN (192.168.5.0/24), and the ISP router is effectively the DHCP Server, that this may lead to broadcast storming or other fatal performance loss in the network because every Client has a dynamic IP. No worries for the number of hosts. With tcpip there is not really an issue with broadcast storms. If you are using an old lan technology like netbeui, spx, or banyan vines then broadcasts would be a concern. With TCP the main type of broadcast are ARP messaging (in general). Regarding the HDD - it’s supposed to be 2 SAS HDD’s in RAID 1, because these are the only harddrives in the paper server. So effectively 1 HDD. I know 200 Mbit’s is much, I’m still debating in changing it to 2 SSD’s. I was just worried they would break faster. One HDD or 2 in Raid-1 same difference since only one is the leader disk an the other is the mirror or follower disk. If you are using a traditional RAID controller then the onboard cache memory will help a bit with performance. But remember you are dealing with multi GB files for imaging so the cache will only help so much. In regards to SSDs, for FOG imaging they will not break faster than HDD. What breaks SSDs is many writing to the drive. In the case of standard fog imaging its a write once, deploy (read) many times. SSDs are ideally suited for FOG imaging. I would say the HDD would have a shorter life because of the head thrashing about the disk when you have multiple imaging going on at the same time. Last thing regarding the Bottleneck … So, the image server cannot deploy faster than his own read speed and the write speed of the Client, right? Here are actually the bottlenecks in imaging. Lets assume a deployment here server->client FOG Server disk to network Network infrastructure Network to fog imaging Fog imaging to disk In the case of a FOG deployment, the fog server does very minimal work. On the FOG server it only moves data from the disk storage to the network adapter and then manages the overall progress of imaging. If you wanted to you could run the FOG server on a Raspberry PI 4 server. The key is getting a fast data path from disk to the network. For fog imaging the target computer does all of the work. The target computer takes in the image from the network, decompresses the image dynamically, and then writes the image to the local hard drive on the target computer. So impacts on deployment speed is network, CPU (Ghz and number of cores), memory speed, and local storage drive. So if you were to setup FOG and deploy to a computer the program that writes the image to disk is called PartClone. PartClone gives a performance number. This is usually in GB/min. This number is actually a composite number that indicates how fast Partclone can write the image to disk. But behind that number is all of the defined bottlenecks. Lets say you take 2 computers one is a 2010 Core2 Duo with a HDD and the second is a 2019 Quad Core with an NVMe drive. Using that same FOG server the Core2 computer will probably deploy in the 4GB/m range (bottleneck is CPU or local HDD). Where that Quad Core with NVMe drive will deploy in the 6.5GB/min range (bottle neck is the 1GbE network)

@Tom-Elliott said in Create Basic Snapin: batch script to directly call the npm binary. Right now, the way your batch file is written, it expects the npm to be set in system path. If you know it’s installed in C:\npm\npm.bat I would Thank you @Tom-Elliott and @Sebastian-Roth. It worked as regular user not as administrator. I have used another solution that is psexec that is a tool that runs the script at all the machines.

@george1421 I figured it out. /dev/nvme1n1 I wasn’t sure how Linux named NVMe’s.

i think i’ve found the solution . i just made a new ipxemenu entry with my winpe and force via API , the default parameter to 1 to this menu entry i can find in coreobjects pxemenuoptions. i’ll keep you informed

@acsand0199 If you have issues post back and I’ll see if I can give you a direction to look in.

@MikeBC I agree. In our imaging lab we are only using wd15 docks the wd19 even after the dock firmware upgrade were just to unreliable reporting to the firmware as pxe compliant. So in the end we moved the wd19 docks to the user’s desk and acquired their wd15 docks for the imaging labs.

@george1421 Thank you. I will delete them shortly to avoid any further issues.

@Sebastian-Roth This is not a new branch, just an upgrade and move from Ubuntu to Centos 7 as it is more stable when upgrading. The only thing I can do as far as getting closer is to move this computer into the server room, but since it is a desktop that would be a little cumbersome. These are juniper switches. For creating the schools’ base image, I use this same machine to do the work for all of them since it is pretty close to the “golden image” for each one. I am using this Dell Optiplex 7040. I create a legacy image (have some more impoverished districts with old machines) and a UEFI image. I have not tried different iPXE binaries and I wasn’t aware that you guys wanted me to do a mirror port. I will try and work on this today if I get some time. Thanks for the guidance.

@george1421 Works great, thanks !

@Sebastian-Roth I chatted with the OP last night and got things worked out. There was a number of things wrong with the setup. We got them worked out one by one. The IP address for the fog server was incorrect in dhcp In the end FOG wasn’t installed completely on the FOG server. Something happened during the install because the .fogsettings file was missing (not very common so it took us a bit to narrow down).

This module appears to have gained some popularity… Maybe I need to find some time to do more updating.

now with that said linux has a command hwclock that can set the hardware clock to local time. That command does exist in FOS Linux, but it appears to have a dependency that is not met. The other missing command is ntpdate to set the FOS Linux clock to some ntp server on your network. So in theory we can get to where you need with a little black magic. ref: https://docs.fedoraproject.org/en-US/Fedora/26/html/System_Administrators_Guide/sect4-synchronizing-date-time-hwclock.html

@init32 said in Need help for a test setup: Your (client) IP address: 192.168.1.229 ****Next server IP address: 192.168.1.1 Relay agent IP address: 0.0.0.0 Above is the problem with soho routers they put themselves as the pxe boot server. This is where we use dnsmasq to override this poor behavior. Well done getting it setup!

Never mind, found the option in settings. Now working fine and just have to change the boot device before letting the client do it’s thing.

@Wayne-Workman said in Feature request for FOG 1.6.x - Scheduled database maintenance: I should add I’m not talking about history. I’m referring to the issues that literally break fog. This stuff: Definitely good you phrase this more explicitely!! We should discuss those two things separately (maybe not in different topics though). While we tell people to sometimes try a cleanup of the DB I am not sure how much issues in the code are still causing this or if this is related to people coming older versions and have not done a cleanup in a long time. Don’t get me wrong, I am not saying the code is perfectly fine, I just don’t know as we don’t have enough evidence that this happens all the time. We would expect way more people to ask about this in the forums. On the other hand I do agree that running those cleanup (not the history ones!) once a week or even daily wouldn’t hurt: DELETE FROM `hosts` WHERE `hostID` = '0'; DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0'; DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0'; DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0'; DELETE FROM `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0'; DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1'); DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`); DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`); You don’t want to run those on a regular basis I find because it can kill running tasks/sessions if those were setup to run over the weekend for example (state ID see here) DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3"); DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3"); TRUNCATE TABLE multicastSessions; TRUNCATE TABLE multicastSessionsAssoc; DELETE FROM tasks WHERE taskTypeId=8; And history is another story altogether… TRUNCATE TABLE history; TRUNCATE TABLE userTracking;

@Tom-Elliott Good thoughts about not focusing on bash scripts. My thoughts on this… At work, if you can point your peers to documentation saying “this project only supports this distribution” Generally your peers accept it. It’s been a topic that has come up before: Dropping installer support down to one or two distributions. CentOS and/or Debian. This probably deserves another forums topic. At this point, I think supporting one distribution is best. I don’t care which one it is, though Debian probably has the best shot at longevity. I fear CentOS will slowly become irrelevant to many as Red Hat focuses on supporting IBM (their parent company), giving less focus to everything else.

There is a nice article on how to setup NFSv4 with a single port open: https://peteris.rocks/blog/nfs4-single-port/

@gwhiteia Well I can either walk you through updating what you need or you can wait until this feature is available in the dev branch. It should take about 15 minutes of hands on time to setup the patch. You will just have to remember to remove it (one line of code) when 1.5.10 is released later this year. The decision is yours.

@jordynorm I am still keen to see the füll DHCP DORA in wireshark to be sure! Best if you can capture directly in the DHCP server (filter for the machine’s MAC address) or using a mirror port on the switch directly connected to the PXE booting machine. There is no need to alter the default.ipxe file.