[YLUG] java.io.IOException

[Roger Leigh]

On Thu, Jul 02, 2009 at 09:08:30AM +0100, Arthur Clune wrote:
> 
> On 1 Jul 2009, at 22:50, Roger Leigh wrote:
> 
> > So the new VPN server doesn't use the existing open standard
> > protocols?
> 
> No. Being free software wasn't (and isn't) a requirement

What about open protocols?  The existing setup works just fine
using standard PPTP, and integrates nicely with the rest of
the networking setup (iptables, routing, etc.).

I need to access services over the network using standard
protocols (ftp, ssh, sftp, rsync); using a web browser doesn't enter
into the equation (for me at least; I can see that others might find
it useful).  While it looks like the command-line client might in
theory provide what I need, in practice it's just not usable, as I've
detailed below.

> > Is it really necessary to install untrusted proprietary code
> > in order to connect to it?  Are any open tools available
> > which can interoperate with it?
> 
> Not that I'm aware of.
> 
> > When is the existing PPTP VPN going to be retired?
> 
> Sometime within the coming academic year.

That's going to be a big problem for me.

* I will no longer have the ability to access the licence server
  I need for the visualisation software I need to run.
* I won't be able to back up my data via rsync.
  I have rather a lot of data (well over >100 GiB at last count),
  and being able to keep a copy on a local backup (RAID1 device)
  by syncing the changes regularly is very important--it's too big
  to copy over by hand using e.g. USB keys.
* git+ssh access to git repositories to push and pull changes won't
  be possible.
* I won't be able to work remotely using files on University systems
  over the VPN either.

I have two systems at home, neither of which will work with the new
VPN system:

1) The main system I use to do backups is a PowerPC-based Debian
   GNU/Linux system.  Sun do not have a JVM for powerpc-linux-gnu, so
   I'm stuck.  It might be possible to get it working using some other
   JVM, but that's well outside my area of expertise.  But the killer
   is that the Juniper software is *i386-only*, so my major use of the
   VPN service will be broken.  The software will never work on
   powerpc-linux-gnu unless it's specifically compiled for this
   architecture.

2) I also have an Intel EM64T system using amd64 Debian GNU/Linux.
   Again, Sun do not have a JVM for x86_64-linux-gnu, so I can't
   use this system either.  Again, it might be possible to get it
   working using some other JVM, but it's similarly outside my
   expertise (but the software is i386-only, so this is moot).  Not
   only would I need i386 versions of the libraries the executables
   depend upon (which is do-able, 32-bit compatibility libraries do
   exist), I would also need 32-bit versions of all the JVM
   dependencies, which is a rather larger task.  It might be possible
   to cross-compile a 32-bit Linux userland to get the JVM to work but
   I really don't have the time to spend on that, since my PhD research
   is a much larger priority, and I'm really working around the
   non-portability of the client software here--it's not my problem to
   fix that, it's the vendor's.

Looking at the package provided on your web page, it's not in any
way portable or platform dependent, despite its use of Java:

% file *
libncui.so:  ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
ncdiag:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
NC.jar:      Zip archive data, at least v2.0 to extract
ncsvc:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
version.txt: ASCII text

Dumping the ELF headers with readelf/objdump shows reasonably small
dependencies (libc, libm, libdl, libpthread, zlib), not counting the
JVM requirement.  However, looking at the symbol table of the binaies,
it's invoking the JVM (or some external programs) by way of system(),
[system at GLIBC_2.0] which is not particularly safe or secure [note:
might be done in libncui.so which requires execlp [execlp at GLIBC_2.0],
but some programs are using system(3)].  It's also not possible to know
what extra libraries it wants to dlopen (if it's the provided
libncui.so, that's badly broken since it can't portably or reliably
know the location to open it from).  The shared library lacks a NEEDED
section for the C++ runtime libstdc++, but that might be linked in
statically.

NC.jar is perhaps better, though there's no way to tell if it has
additional platform-specific dependencies without decompiling or
investigating using more Java-fu than I possess (not possessing a
system which can support Sun's JVM or JDK does not help here).

The bottom-line is that it's i386-only, and I don't have an i386
computer system.  "Linux" is not supported unless your system is
i386-linux-gnu.

In summary, the two major issues are:

* the i386 ELF binaries, which restrict the software to i386-linux-gnu
  (and potentially x86_64-linux-gnu with suitably cross-compiled
  compatibility libraries).
* the lack of JVM availablility on common platforms (x86-64 is the
  most commonly available non-embedded platform AFAIK).
* So you need *both* an i386-compatible system *and* a working JVM for
  the software to function.

The existing service just talks PPTP, clients for which are available
for every GNU/Linux system out there.

I make regular use of the existing VPN setup, and I am completely
dependent upon it functioning to do certain tasks.  Not being able
to use it in the future will be quite detrimental to some of my
work.  Hopefully this feedback is useful to you, and any suggestions
you could make on this would be appreciated.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.lug.org.uk/pipermail/york/attachments/20090720/c23342af/attachment.pgp