Archive for the ‘suse’ Category

FTPS (aka “FTP secure”, aka FTP-SSL (and not SFTP)) and apache proxy

Thursday, August 13th, 2009

So FTPS is encrypted (via SSL) FTP. It’s a definite step up from regular unencrypted FTP. It is not to be confused with SFTP, which IMHO is a misnomer as it’s not really FTP at all but rather a sub-system of SSH. For the below we’re talking about ‘explicit’ FTPS, meaning it uses the normal FTP port and negotiates encryption (‘implicit’ uses a dedicated port). But anyways, if you’re still here you probably know most of this…

I like to proxy all outgoing connections from any infrastructure I set up. The reasoning is something along the lines of: why should your web server be browsing the web? Basically, servers should never be allowed to initiate connections to the outside world. I’ve had firsthand experience of servers being exploited (an OpenSSL hack comes to mind) where the exploit worked but the server was unable to connect back to the outside world, preventing the bad guy from being…bad. Where a server does need to need to initiate a connection to the outside world, it should be as restricted as possible, and via proxy. With a proxy you can control the outgoing connections of all your hosts at a single point, as well as monitor all traffic if need be. It recently came to be that an app was going ballistic in my current infrastructure, making thousands of requests a second to an outside service and effectively DoS’ing it. One change to the proxy server blocked all requests to that specific external host until the engineers could reign in the app. I didn’t need to find the app making the requests…just do the blocking at the proxy. I generally set up a load balanced VIP which has two proxies behind it, for redundancy.

Anyways, I use Apache proxy as it’s easy and free and works great for my simple proxy-ing needs. The issue came up recently that an app needed to make outgoing FTPS connections. I thought this would work without any changes as FTP outgoing proxy was already configured (mod_proxy_ftp) as was mod_proxy_connect, used for proxy-ing outgoing HTTPS requests. The one gotcha that prevented it from working and took a little bit to figure out was the AllowCONNECT directive:

The AllowCONNECT directive specifies a list of port numbers to which the proxy CONNECT method may connect. Today’s browsers use this method when a https connection is requested and proxy tunneling over HTTP is in effect.

By default, only the default https port (443) and the default snews port (563) are enabled. Use the AllowCONNECT directive to override this default and allow connections to the listed ports only.

As FTPS uses SSL and hence CONNECT when making a proxy request, we need to open up port 21. Basically:

AllowCONNECT 443 21

And all is good.

jeff

SuSE 10 enterprise server RUG errors after SP1 upgrade

Wednesday, September 19th, 2007

After upgrading a bunch of SLES 10 servers to SP1, some (but not all) servers were now getting 401 Login Failed errors when doing a rug refresh (or any rug actions) from novell’s update servers. On some servers, deleting the update sources in Yast2 and reregistering via the customer center solved the issues, but on some it did not. (The issue only occurred on servers I upgraded to SP1, not where I did an install from SP1 sources.)
On the problematic ones:
Those update sources were listed as ZYPP sources, not NU. (I was letting yast create them via synchronizing with zenworks)
I had to:
remove old services:
rug sd SLES10-SP1-Online
rug sd SLES10-SP1-Updates
Add the new one (with the type specified, or it errored):
rug sa -t nu https://nu.novell.com

Subscribe to the new catalogs:
rug ca

Sub’d? | Name |
Service
——-+——————————————————–+——————————————————-
Yes | SUSE-Linux-Enterprise-Server-i386-10-0-20070605-044231 |
SUSE-Linux-Enterprise-Server-i386-10-0-20070605-044231
| SLES10-SP1-Online |

https://nu.novell.com

| SLES10-SP1-Updates |

https://nu.novell.com

| SLE10-SP1-Debuginfo-Updates |

https://nu.novell.com

#rug sub SLES10-SP1-Online
Subscribed to ‘SLES10-SP1-Online’

#rug sub SLES10-SP1-Updates
Subscribed to ‘SLES10-SP1-Updates’

rug worked then, but I still had 401 errors in Yast2 (when going to
online update, customer center, or installation sources)

To resolve them, I then had to remove the update sources in Yast2,
re-run the Novell customer center configuration, and then things seem OK.

“Linux kernel must be loaded before initrd” error with Autoyast in SLES SP1

Wednesday, August 15th, 2007

Something odd that may save some people time to figure out…The same autoyast files that worked fine with SLES 10 suddenly started generating “Linux kernel must be loaded before initrd” grub errors when I was using SLES10 SP1 install sources. Easy enough to fix interactively (insert a line specifying where the kernel is), but why is it happening, and how to automate? (All systems administration really gets to the point where you are just automating things. You don’t want to have to rely on people to DO things, or you will be disappointed.)

Rather than go and pore through the release notes in the hope that I could glean what may have changed, I just did a manual install over the network, and compared the generated reference autoyast file to the one I was serving from my boot server. This is what I found:

In the bootloader section of your autoyast.xml file, rather than

<section>
        <append>resume=/dev/sda1  splash=silent showopts pnpacpi=off</append>
        <initial>1</initial>
        <initrd>/boot/initrd</initrd>
        <kernel>/boot/vmlinuz</kernel>
        <lines_cache_id>1</lines_cache_id>
        <name>SUSE Linux Enterprise Server 10</name>
        <original_name>linux</original_name>
        <root>/dev/sda2</root>
        <type>image</type>
      </section>

just add a line

        <image>/boot/vmlinuz</image>

before the kernel line.

That will get your installation to complete, but not to boot correctly after the install. For that, you also need these lines:

      <activate>true</activate>
      <boot_root>true</boot_root>

in the global section of the bootloader section.