Bug 72398 - firstboot ntp option should be greyed out if high firewall picked in install
Summary: firstboot ntp option should be greyed out if high firewall picked in install
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: firstboot   
(Show other bugs)
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-23 14:24 UTC by Telsa Gwynne
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-28 19:13:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Telsa Gwynne 2002-08-23 14:24:33 UTC
GUI install of (null) personal desktop.

Firewall options in installer left as high. First boot is offering me the 
chance to start ntp running. I don't think this will work, will it..?

I think it should be greyed out if UDP traffic is being dropped, if this
is possible.

Comment 1 James Manning 2002-08-23 17:47:17 UTC
I selected High during install, during firstboot I selected to use ntp and
selected terrapin.csc.ncsu.edu for the server, and now it's hung (has been for 9
minutes as I write this).  The firstboot is "locked" (switching to a text vt and
then back, the firstboot dialog isn't redrawing).  Since I have no shell to do
anything else, I'm going to have to reboot, but ctl-alt-del isn't working on vt1
(is that not configured for init by default on the first boot?).  Ack - power
cycle time.

ok, on second try, i left ntp turned off and firstboot ran fine.  I could be
mistaken, but isn't ip_conntrack supposed to handle associating udp as well (it
has for me in the past with things like quake3, also udp based).  I know it's
major role is in the ESTABLISHED,RELATED state stuff, but maybe just
modprobe'ing ip_conntrack (i don't see a module specific for udp) or perhaps
just installing a rule to enable UDP NTP traffic from the selected server
(*before* attempting the actual ntp action :) would suffice?

Actually, that makes more sense - whichever server is selected should have an
iptables rule added on the spot and then a "service iptables save" (or whatever
route) to make that more permanent since in the case where ip_conntrack can't
associate the outgoing ntp request and an incoming response (which I *think* it
can do, but I could be mistaken), this rule will be needed long-term.

Course, if there are config program code paths that can change the ntp server,
they'll need this iptables logic as well, I'd imagine, to remove the old one(s)
and add the new one(s)

At least, this is all AFAICT of course

Comment 2 James Manning 2002-08-23 17:48:21 UTC
forgot to restate that since the later stage of RHN registration worked fine,
there's no issue about "was networking working" - the "hung" state of the NTP
attempt is 99% likely due to the High firewalling selection during the install.

Comment 3 Brent Fox 2002-08-26 16:20:05 UTC
The initscript for ntp4.1.1a-7 will now poke a hole in the firewall to allow NTP
connections to pass through.  

QA, please verify.

Comment 4 Gene Czarcinski 2003-01-28 14:35:41 UTC
verified ... this should be closed

Comment 5 Pat 2003-11-09 01:31:17 UTC
Can this be re-opened? I am seeing this with Fedora Core Test 3 and
Fedora Core 1. 
I had the default firewall enabled (with SSH opened), and then I tried
to enable clock synchronization in Firstboot. Fedora core hung for 30
minutes. I had to restart my computer, and not choose that option to

Note You need to log in before you can comment on or make changes to this bug.