Posts made by rogalskij

@kafluke I also was experiencing this same issue. I had deleted a bunch of data as well before trying to pull the image (ran disc cleanup wizard). I ran the exact commands you did, and it fixed the issue. Thank you and Quazz for this assistance. This forum really helps in every way with this awesome product.

@george1421 Hey there George, I thought 1.5.8 was released this morning? At least that is what my FOG login page told me. Am I incorrect? Should I wait you think?

@Tom-Elliott I noticed that a bunch of services haven’t started for me as you suspected! Wow my server is functional and works and I am not even sure how?!

I ran “systemctl --failed” and this is what I get:

[root@clone ~]# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● FOGImageReplicator.service loaded failed failed FOGImageReplicator
● FOGImageSize.service loaded failed failed FOGImageSize
● FOGMulticastManager.service loaded failed failed FOGMulticastManager
● FOGPingHosts.service loaded failed failed FOGPingHosts
● FOGScheduler.service loaded failed failed FOGScheduler
● FOGSnapinHash.service loaded failed failed FOGSnapinHash
● FOGSnapinReplicator.service loaded failed failed FOGSnapinReplicator
● nrpe.service loaded failed failed SYSV: A simple script to autostart NRPE and allow us to easily reboot

I am going to check my server. Poor thing is an older Dell Poweredge running CentOS 7 so maybe it is just tired and slow and network or the database doesn’t start fast enough for the services?

@george1421 Thank you. I am going to update the FOG server to 1.5.8, and we will see if it fixes it. I checked and both my servers (we have 2 campuses so I set up a server on both locations) do this exact same behavior. Could be something I did wrong during install of course, but I will report back after the update to 1.5.8. Thank you for this speedy help!

My apologies if this question has already been asked. I tried to find the answer on the forum but couldn’t find it. I would like my FOG 1.5.7 server to start the mutlicast manager service automatically after a server reboot. I ran the “systemctl enable FOGMulticastManager” command but it seems to failt to start by default after a reboot. I have to start the service manually myself. When I check the service status after a reboot I get “failed”.

Is there something I need to be doing differently? I checked that the service is set to “enabled” but it still won’t start. Any thoughts?

After a reboot (ip and names blurred for security reasons):

Hello, I have a functioning FOG server that runs well. One small thing I am wondering is if we can make the server email only the user who is actually doing the imaging? What we would like is user “smith” starts an image, it completes, it emails user “smith” only.

Right now we have it set statically so that it emails a specific person no matter who does the imaging. Is there a variable we could set in the “Email Address” field, like “{USER}@emaildomain.edu” or something of that nature? I don’t want to mess with API’s or anything like that, but if there is a variable I will use it.

Any assistance is appreciated. Thank you much FOG pros!

I appreciate the quick reply Tom. I was just curious if there was already a quick check box to turn this off or not. I think I will hold off on it and just let my team know they need to be sure to approve hosts after installing the client. I appreciate your insight and look forward to a possible feature addition in the future!

Is there a way to have hosts I install the client on automatically approved in the “hosts” section of FOG? We keep pretty tight controls on software installs, and I would like to not have to go into the server and “approve” the pending hosts that I see. A couple times we have forgotten and it temporarily delayed us from imaging a lab full of computers because they weren’t “approved” yet.

Any assistance with this would be appreciated. It seems like a small step but when we are adding hundreds of hosts to the system it really can slow one down. Thank you all I appreciate you!

-Josh-

Found the issue! After some research and discussion with Cisco, we had to add “PIM” to the vlan on our core, even though both the server and client are both on the same vlan!

Used the command - ip pim sparse-dense-mode on vlan 1 interface and it started working like a charm! I really appreciate everyone’s assistance here. This will help our institution so very much.

@Tom-Elliott Good thinking, I just attempted that but it seemed to make no difference. My clients still seem to hang on the partclone screen. I did reach out to Cisco to check to see if my 6509E core switch has all the correct settings on it for multicasting. I also made sure the port the server was on is using “port-fast”. It worked like a charm the moment I plugged it into the edge switch. I will do some more testing while I wait for Cisco to answer me back. Sorry for all the back and forth with this, I really do appreciate this product, it’s developers, and the dedicated community behind it.

Ok more developments, we found when running the udpcast commands to test, the tests failed. I switched the Poweredge server (where FOG is installed) over to the same Cisco 2960S switch as the target computers and multicast worked perfectly!!! So it seems to be something with my Cisco 6509E core switch. I checked to make sure IGMP snooping was enabled on the core, but other than that I am unsure what to check. Any thoughts?

@Sebastian-Roth I will be testing again today. My apologies on this taking so long. I will report back.

@george1421 After a reboot there is no change. The computer is still deploying images via unicast without an issue. I updated the Kernel to the latest version, no change. One question, could I have the interfaces for multicast set wrong? Is there a way to check on the CentOS server what they are really named? Also inside the system can I check this? Just in case the WebUI is reporting it back incorrect?

@george1421 We use Cisco C2960S switches in those labs. The core is also Cisco.

@george1421

Some additional information and questions:

I enabled “igmp snooping” on all of the switches and I verified that it is enabled on the switch that lab full of computers sits under.

I am happy to review the multicast settings. I put them in the main body of this post, do they look correct?

How do I check the firewall on the fog server (CentOS 7). I am pretty sure I disabled it entirely but can’t remember.

I did a config restore from my dev system which was a virtual machine. Could this be screwing something up? Something brought over incorrectly?

@george1421 Yes, when I capture or deploy an image using Unicast, everything is happy ducky wonderful. Images capture and deploy without an issue what so ever.

@george1421 Yes, I have the “em1” interface of the FOG server, and the network card of the Dell Computer I am trying to image on the same subnet.

The output of the “ip addr show” command on the FOG server is:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d4:ae:52:af:b5:63 brd ff:ff:ff:ff:ff:ff
    inet 150.155.1.70/20 brd 150.155.15.255 scope global noprefixroute dynamic em1
       valid_lft 704372sec preferred_lft 704372sec
    inet6 fe80::3d39:c85:7bf0:e61e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: em2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether d4:ae:52:af:b5:64 brd ff:ff:ff:ff:ff:ff

@george1421 Wait, you aren’t allowed to have the FOG server on the same subnet as the clients?! This is how we do most everything right now. We plan to subnet our devices later on, but previously with Ghost and other multicast products we just multicast with devices and the server on the same subnet. Is this still possible?

Additionally, the output of the command you specified “sudo ps aux|grep udp-sender” is:

root 13864 0.0 0.0 115300 1480 ? S Aug30 0:00 sh -c /usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 1200 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p1.img;/usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 10 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p2.img;
root 14393 0.0 0.0 8688 660 ? S Aug30 0:00 /usr/local/sbin/udp-sender --interface em1 --min-receivers 3 --max-wait 10 --portbase 56590 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/BaseImage/d1p2.img
root 31094 0.0 0.0 112708 992 pts/0 S+ 11:39 0:00 grep --color=auto udp-sender

As you can see, it sees the interface em1, unless I am wrong and em1 isn’t the name of the interface, but that is what it says when I do an “ip addr” command on the server.

@Sebastian-Roth I checked the Apache log you mentioned, but all I see from that day doesn’t make a ton of sense to me:

[Fri Aug 30 15:25:11.052318 2019] [mpm_prefork:notice] [pid 2739] AH00170: caught SIGWINCH, shutting down gracefully
[Fri Aug 30 15:28:26.997884 2019] [core:notice] [pid 2727] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Fri Aug 30 15:28:27.032137 2019] [suexec:notice] [pid 2727] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Aug 30 15:28:27.101535 2019] [lbmethod_heartbeat:notice] [pid 2727] AH02282: No slotmem from mod_heartmonitor
PHP Warning: Module ‘ldap’ already loaded in Unknown on line 0
[Fri Aug 30 15:28:27.268250 2019] [mpm_prefork:notice] [pid 2727] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.2.21 configured – resuming normal operations
[Fri Aug 30 15:28:27.268287 2019] [core:notice] [pid 2727] AH00094: Command line: ‘/usr/sbin/httpd -D FOREGROUND’

Does this make sense? Am I looking at something wrong here?

@george1421 Yes, they are both on “vlan 1” for the moment. Both are on the same subnet.