Jeff Johnson wrote:
>
> ;-) Actually the whiplash is mostly just a crick in the neck these days,
> mostly that the current implementation http implementation does
> not support redirects.
>
> I'll likely replace the "r.ufdio" with a macro for each Fopen so that
> users/distros can control whether, say, queries should be network
> aware, but installs should not be permitted network access.
>
> That implementation of policy is easier than rehashing the issue Yet 
> Again.

That would be a great choice I think, and one that avoids possible neck 
injuries. :) Configurability is always nice when the developer is 
willing to code for it.

>
> rpm-4.5 (and rpm-5.0) are both headed for release over the next 2 months.
>
>

Wow, I didn't realize both were so close to a release. We're definitely 
excited about updating our crusty RPM 4.1 on Solaris 9. All of this 
trial and error getting 4.4.9 to work has been intentionally done in 
order to ferret out any problems before the next major release. Getting 
apt-rpm to work is a whole other saga...

>
> Ultimately, on Solaris, you likely want rpm-5.0, which has a considerably
> more portable and maintainable build configuration than rpm has ever had
> before.

Probably. If the 4.5 is release slightly ahead of 5.0 I'll probably be 
building it just as a stepping stone, but we're definitely waiting for 
5.0 before any production systems are rolled out, it's just too nice of 
a release to jump the gun on (especially considering how long we've been 
running 4.1) At this point our internal build seems to be working 
nicely, so barring any unforeseen problems 5.0 is the ultimate goal.

>
>>> Still no idea what the EPASV vs PASV problem root cause is.
>>
>> Is this actually a problem on your end? We are fairly certain that 
>> our L4 is choking on the EPSV NAT translation vs. the more common 
>> PASV, so this might not actually be an rpm issue, unless you saw 
>> something otherwise. It looks like Tim was experiencing the same 
>> ufdio/fdio issue and hadn't gotten to any FTP transfers (hence his 
>> mention of ftpdebug not working). Jeff, you might have just tipped us 
>> off on a networking issue specific to our case, which I thank you for 
>> ;) hah.
>>
>
> Not a problem on my end, but Tim has said that a Solaris rpm client 
> could not
> access a RHEL vsftpd server.
>
> But there are 2 problems, EPSV and non-functional ftp, that might explain
> all the known issues.

Ok, the real point of this reply... I did some testing today to finally 
rule out RPM as a potential problem in the EPSV issue. We know that the 
non-functional ftp problem was all because of networking needing a kick 
in 4.4.9 for Solaris, so that can be disregarded in our case at least. 
With that out of the way, I went on to test our theory of bad L4 
translation of EPSV in the network, and I can confirm that it was in 
fact the problem. With one machine behind the L4 firewall and one 
public, RPM over ftp functioned as expected for the public server and 
hung on the ESPV connection through the L4. At that point I switched off 
EPSV in proftpd and it failed over to PASV and worked. It seems that 
there are some routing issues with EPSV and config changes are in order.

What does this mean for rpm, not much unless you want to implement a 
timeout and PASV failover for the rare case of this happening. ;) 
Anyways, thanks Jeff for finding a networking bug that we didn't know 
existed! I appreciate it.

-Dave

-- 
================================
David Halik
Systems Programmer
OSS/NBCS - OIT Rutgers
dhalik@jla.rutgers.edu
================================