Bug 153467

great.

starting shell
chokeberry:/ # 
chokeberry:/ # ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0d:60:1e:80:16 brd ff:ff:ff:ff:ff:ff
    inet 10.10.2.216/16 brd 10.10.255.255 scope global eth0
    inet6 fe80::20d:60ff:fe1e:8016/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0d:60:1e:80:17 brd ff:ff:ff:ff:ff:ff
    inet 1.1.1.3/24 brd 1.1.1.255 scope global eth1
    inet6 fe80::20d:60ff:fe1e:8017/64 scope link 
       valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
chokeberry:/ # iptables -L -n -v
Chain INPUT (policy DROP 118 packets, 12872 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           

Chain reject_func (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset 
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-proto-unreachable 

Reinhard: Can you help here? If not, assign it back to us.

Not being able to connect with vnc is only the symptom. The reason -as Comment #2 indicates- is the network/firewall setup, and that's not my area of responsibility.

Olaf: Where do you think the problem is located? Invalid firewall-settings or faulty network setup?

I think the firewall is already configured in boot.localnet, where localhost is configured. Maybe there is a call in yast2 to open the firewall and ssh ports as needed. It does work for a fresh install at least. But I havent checked how the iptables output looks like for a fresh install before y2base is called.

If you suspect YaST to be (part of) the problem, please attach the y2logs.

update beta4 -> beta6:
...
reating /var/log/boot.msg                                            done
Starting Firewall Initialization (phase 1 of 2) NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (1920 buckets, 15360 max) - 296 bytes per conntrack
                                                                      done
Activating remaining swap-devices in /etc/fstab...                    done
Setting current sysctl status from /etc/sysctl.conf
...

System Boot Control: Running /etc/init.d/boot.local
dingleberry:/ # 
dingleberry:/ # lsmod
Module                  Size  Used by
ip6t_REJECT            24928  3 
ipt_REJECT             24632  3 
xt_state               19592  2 
iptable_mangle         22048  0 
iptable_nat            30236  0 
ip_nat                 43926  1 iptable_nat
iptable_filter         21800  1 
ip6table_mangle        22168  0 
ip_conntrack           98516  3 xt_state,iptable_nat,ip_nat
nfnetlink              27072  2 ip_nat,ip_conntrack
ip_tables              36968  3 iptable_mangle,iptable_nat,iptable_filter
ip6table_filter        21792  1 
ip6_tables             38696  2 ip6table_mangle,ip6table_filter
x_tables               37648  6 ip6t_REJECT,ipt_REJECT,xt_state,iptable_nat,ip_tables,ip6_tables
ipv6                  464992  11 ip6t_REJECT
apparmor              100616  0 
aamatch_pcre           34720  1 apparmor
loop                   41272  0 
dm_mod                115464  0 
tg3                   154508  0 
dingleberry:/ # iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           

Chain reject_func (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset 
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-proto-unreachable 
...

so yast has to open the gates for ssh and vnc as needed.

maybe its not yast this time.

/usr/lib/YaST2/startup/YaST2.call
...
*** Starting YaST2 ***
starting shell
dingleberry:/ # iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain reject_func (0 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset 
REJECT     udp  --  anywhere             anywhere            reject-with icmp-port-unreachable 
REJECT     all  --  anywhere             anywhere            reject-with icmp-proto-unreachable 
dingleberry:/ # rcSuSEfirewall2 stop
Shutting down the Firewall                                            skipped
dingleberry:/ # iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain reject_func (0 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset 
REJECT     udp  --  anywhere             anywhere            reject-with icmp-port-unreachable 
REJECT     all  --  anywhere             anywhere            reject-with icmp-proto-unreachable 


so stop really means stop as in open the damn thing.

SuSEfirewall2_setup does not unload the rules upon shutdown on purpose. It thinks its in shutdown mode when $REDIRECT is set, file a separate bug if you know a better method. Use SuSEfirewall2 stop instead of rcSuSEfirewall2 stop to unload the rules unconditionally. I fail to see how this is related to your problem with the closed vnc port though.

the bug is that this thing runs now in boot.d instead of rc.N.

you typed rcSuSEfirewall2 stop manually yourself. No script runs that in boot.d.

anyway, someone has to open the gates to let the admin in during upgrade.

still broken in beta7

still broken in beta8

i think this is more a yast2 problem?

olh: is that bug about this scenario?

- Let's have an installed 10.1 Beta4 (with VNC closed in firewall)
- Boot inst_sys from net/CD/DVD with inst_source from NFS, installation over VNC and SSH
- Connect via VNC
- Select "update", run update until the system gets rebooted
- Reboot the system to 
- Then something or someone starts the Firewall and you cannot connect to VNC

mvidner: can it be somehow related to network configuration? starting firewall before the update continues?

the bug is that we have a "firewall" active that early in the first place.

Yes, but, does the written scenario match the current problem or doesn't?

yes, thats whats happen. testhost chokeberry.

lnussel: would you have any proposal for this situation?
Comment 16-19
Maybe Firewall isn't completely started and YaST-2ndStage should be launched just after the firewall is completely started or before the firewall_init is started?

If the firewall is configured to open the vnc port just run SuSEfirewall2 to make it set up the full ruleset. I guess only SuSEfirewall2 close was run at the time yast started.

I just cannot start / restart SuSEfirewall when I want. By the way yast2-firewall has nothing to do with it.

Either YaST should be started after the Firewall is up and running or YaST starting script should do something with the Firewall (complete start, complete unload). I don't think that YaST starting script (installation) does something by now. But if it did something it would be a bug for Marcus :) -> ms

Marcus, could you, please talk directly with Ludwig about it?

yes startup scripts doesn't do anything with the firewall :-)

Talked with Ludwig on the phone, he is currently testing this
and will comment on this bug after he has finished

- YaST does not reconfigure SuSEfirewall2 to allow vnc if vnc is used for upgrade
- some magic in the background called SuSEfirewall2 twice on my test installation (DHCP used for installation). If SuSEfirewall2 had been configured properly the port would have been open.

So what needs to be done to resolve this bug is to 1. teach yast to open the necessary ports (or declare that ports must be open before upgrade), 2. find out what kind of magic causes those SuSEfirewall2 calls and whether this is deterministic (udev?).

Created attachment 77160 [details]
/var/log/messages

There are several ifup/ifstatus calls and two calls to SuSEfirewall2 according to that log.

Created attachment 77162 [details]
y2logs

Thorsten, yast2-firewall doesn't configure firewall during update. This might fail when used had a running firewall (on SLES9, for instance) and updates to SLES10 via VNC or SSH. After the system is rebooted and should continue with the second stage installation, user cannot connect to the computer because firewall blocks it.

The problem is, that we don't have firewall proposal in the first stage installation (update). Should I create some proposal there or should the YaST starting script open a hole in the firewall for VNC in case of VNC installation, and/or for SSH in case of SSH installation?

This is something for the release notes or handbook. We should not fiddle with the firewall settings on update.

Karl, please, see comments
16-27 => release notes, or ...

Thanks

For the box, I can add something to the release notes (if you think that it is necessary).

For SLES, I still can add important issues to the update section of the manual.  In either case, I depend on details input because this is security related.

PLease add something to the release notes.

Something as follows?

Preparing Remote Update
=======================

Before starting an remote update (for example with VNC), make sure the firewall of your system is properly configured.  Open ports required to access your system remotely. etc.pp.


If that's what you want me to add, I can add more details.

Yes, that's good.

ok.  I'm going to submit the following section:

  <!-- Bug 153467 -->
  <sect3 status="2006-04-12" id="remote-update">
   <title>Preparing for Remote Update</title>

   <para>
Before starting a remote update (for example with VNC), make sure the firewall
of your system is configured accordingly.  Use &yast; to open the ports that
are required to access your system remotely.  Start the &yast; Control Center.
Then click "Network Services" -> "Remote Administration" and select "Allow
Remote Administration".  If necessary, activate "Open Port in Firewall".</para>

   <para>Read the &yast; help text for more information.</para>
</sect3>

-> /work

that statement is nice, but even if you do it correctly, nothing will work.

has anyone tried 10.0 vnc install and an vnc upgrade to 10.1? it doesnt work...

thats the state after an upgrade from 10.0, right before the y2base call:

snowberry:/ # grep -ri ssh /etc/sysconfig/SuSEfirewall2 
#     designed with security in mind (like postfix, vsftpd, ssh),
# Examples: "ssh", "123 514", "3200:3299", "ftp 22 telnet 512:514"
FW_SERVICES_EXT_TCP="5801 5901 ssh"
# TCP ACK packets or interactive SSH.
snowberry:/ # iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain reject_func (0 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset 
REJECT     udp  --  anywhere             anywhere            reject-with icmp-port-unreachable 
REJECT     all  --  anywhere             anywhere            reject-with icmp-proto-unreachable 

a /etc/init.d/SuSEfirewall2_setup start would kind of fix it.
is anyone familar with the internals of our "firewall" scripts?

So whether or not the full firewall gets fully started is not deterministic. Therefore I'd suggest adding rcSuSEfirewall2 reload to /usr/lib/YaST2/startup/Second-Stage/S07-medium.

Created attachment 79614 [details]
suggested patch

package submitted.