Forums

Resolved
2 votes
Hello.

I woke up this morning and attempted to remote into one of our classrooms to prepare for a class - none of the computers would appear on the network. On the way in, the receptionist texted me, "no internet in classroom 3."

Upon arrival, there are no IP addresses being assigned to any of the networks I have set as "Hot LAN." Changing them to LAN gets them working but we don't wish to leave it this way.

I do have the custom firewall app installed, and attempted "$IPTABLES -I INPUT -p udp --dport 67:68 -j ACCEPT" to no avail.

Everything was working Monday. It's difficult to pinpoint the exact time of failure as the problem wouldn't manifest itself until any existing leases expired. I see app-dns-core updated early this morning, and while that's not dhcp-related I know both use dnsmasq...
Wednesday, February 05 2020, 03:02 PM
Like
1
Share this post:

Accepted Answer

Wednesday, February 05 2020, 03:25 PM - #Permalink
Resolved
2 votes
The exact failure is the update of app-dns last night for which I have to apologise. If you don't run docker or libvirt/KVM, please go to /etc/clearos/dns.conf and change docker_and_libvirt_only to "yes" then run /var/clearos/events/network_configuration/dns.
The reply is currently minimized Show
Responses (5)
  • Accepted Answer

    The009
    The009
    Offline
    Thursday, February 06 2020, 01:25 AM - #Permalink
    Resolved
    0 votes
    You really should be making announcements about this type of thing.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 06 2020, 08:22 AM - #Permalink
    Resolved
    0 votes
    About what the bug? There was already this post and the only place to make an announcement is here on the forum. Also, once I knew of the issue, I pushed a fix to disable this feature then I was on a call with a customer until past 10pm and, by that time I was pretty tired.

    We do try to catch bugs before they go to the Community but this one slipped through. That is the purpose of the Community/Paid model, so the Community effectively do the final QA before packages are released to paid subscribers.
    The reply is currently minimized Show
  • Accepted Answer

    The009
    The009
    Offline
    Thursday, February 06 2020, 03:00 PM - #Permalink
    Resolved
    0 votes
    Sorry I did not mean to sound rude.

    What I was suggesting is now that you know this exact bug has happened and I am sure many more people will have it. I was just suggesting putting into the bug list that everyone can read and solve easier.

    I checked there did not see anything had to come here to find it. ( https://tracker.clearos.com/my_view_page.php )

    Thank you for all the work you all do for us, I do know how much of a PITA it all is.

    Nick Howitt wrote:

    About what the bug? There was already this post and the only place to make an announcement is here on the forum. Also, once I knew of the issue, I pushed a fix to disable this feature then I was on a call with a customer until past 10pm and, by that time I was pretty tired.

    We do try to catch bugs before they go to the Community but this one slipped through. That is the purpose of the Community/Paid model, so the Community effectively do the final QA before packages are released to paid subscribers.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 06 2020, 06:04 PM - #Permalink
    Resolved
    0 votes
    We are trying to kill off the tracker and I'm slowly migrating the issues to GitLab. This bug is not particularly referenced but is part of issue #5 on GitLab.

    Not too many people will hit the issue as it is only with HotLAN's and DMZ's. So far only three reports, two on the forums and one by a paid customer who also had a Community box. The issue is simple. The function get_trusted_networks that is called does not return DMZ or HotLAN interfaces and to make things worse app-network is out of bounds for changes for the moment because of a big code merge.

    The devs have tried mirroring the Iface_Manager.php from app-network into app-dns then adjusting it a bit, but unfortunately it is hitting what I think is a race condition with the events that are fired when /etc/clearos/network.conf is changed. Sometimes it works and sometimes it doesn't and skip the interface you've just changed. Running /var/clearos/events/network_configuration/dns on its own then fixes it except for once and I cannot reproduce it to get into that failure mode. This is a pain.

    Everyone should be working now as I released an update yesterday to pref it off and delete /etc/dnsmasq.d/bind.conf then restart dnsmasq.

    Somehow it would be a good idea to get this patch out but I'm not sure how ant the moment. The devs will look at it in the morning.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 10 2020, 06:46 PM - #Permalink
    Resolved
    0 votes
    There is now an updated version available for testing. For anyone who can test, please do a:
    rm -rf /var/cache/yum/
    yum update app-dns --disablerepo=* --enablerepo=clearos-updates-testing
    You should receive app-dns-2.7.9-1.v7.

    [edit]
    Just in case it does not work, downgrade instructions are as before.
    [/edit]
    The reply is currently minimized Show
Your Reply