Posts made by jmvela2x

I have two users (using the Access Controls plugin) and want to limit the menu items available to one user. Is there a way to set the menu up to have a login on initial boot and based on the credentials entered, limit what options are displayed? I want everything to be seen by admin users and technician users should only see Memtest and Deploy Image.

@Sebastian-Roth Perfect. Looks good now!

@jmvela2x It appears to work as intended. I did see one error in the FOMulticastManager status output that may be a cause for concern. Expected? multicast05202020_2.log

@Sebastian-Roth Will do and report back.

@jmvela2x I’m still seeing the same issue after an update to 1.5.9-RC2.3 this morning. Attached multicast log. multicast05262020.log

@Sebastian-Roth I will give it a test today and let you know. Thanks!

@jmvela2x Updated to 1.5.9-RC1.11 today and am still seeing the stale task issue. Hosts are waiting for all to join session before multicast begins. Attached log sample: multicast_stale.log

@Sebastian-Roth On 1.5.9-RC1.8. Same server as me.

@Sebastian-Roth Sounds good. Thanks!

@Sebastian-Roth I seem to recall seeing systems start without waiting in 1.5.8. I guess I didn’t realize that was not by design. Currently I see the hosts waiting and the Multicast log shows a single PID. However, the task does not auto delete and as I just tested, I am able to start another group of hosts to join the same session post completion (after the first multicast deployment completed).

@Sebastian-Roth Yes, still talking ‘multicast session created via web UI -> images view and joined through the PXE menu.’ I had no other issues from 1.5.8 release that I could tell except for the failure to auto-delete multicast tasks.

@Sebastian-Roth I still see the same issue where the multicast task is stuck at “in progress” and continues to run according to the logs. The job finishes successfully, but the task does not auto delete. Updated to 1.5.9-RC1.8 and rebooted server. Checked twice, same issue as before.

@george1421 Finally heard back from IT and we have Catalyst 4510r+e in the router department. From some of the documentation I’ve been looking at it seems they have mroute and IGMP Proxy capability. Might need some guidance in that department if anyone has the knowledge or experience.

@Sebastian-Roth That works for the time being. I can just manually cancel the tasks on completion since this is still in validation on our side. Thanks a ton!

@Sebastian-Roth I will hold off on changing anything until I hear from you tomorrow. Thanks for the follow up.

@Sebastian-Roth I did try several reboots and cleared all the tasks each time to make double sure. The multicast session is being scheduled from the Images tab with a defined client count as we are trying to avoid host registration as the hosts in our environment are not static per se. The amount of work required just makes FOG an nonviable solution for us if have to do host registration for all our clients.

@george1421 I’m pretty sure we’re covered on this front, but I will run this by our network guy.

@Sebastian-Roth I may have an opportunity coming up soon to test this in our production environment, but without multicast working in 1.5.9-RC1.4 I will lose the chance. Barring some kind of fix in the very near future for this issue, can you advice on how to roll back to 1.5.8 so I can at least test functionality of multicast cross-subnet in terms of bandwidth usage, etc when the opportunity presents itself?

@jmvela2x I see something potentially relevant in the status output of the FOGMulticastManager service.

“PHP Warning: proc_get_status(): supplied resource is not a”(vailable) I presume is the ending, but it’s cut off in the terminal.

@jmvela2x I didn’t even have the chance to join the clients to the session.