[ANN] nixio 0.3 - System, Networking and I/O library

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] nixio 0.3 - System, Networking and I/O library

Steven Barth
Hi Everyone,

I'm happy to announce version 0.3 of nixio, a well-documented multipurpose Lua
library offering system, networking (IPv4, IPv6 and UNIX), I/O (Files, Pipes,
UDP-, TCP-, and TLS-sockets), byte manipulation, hashing and other useful
functionality.

nixio is FOSS under the Apache 2 license and has been successfully compiled
under Linux/glibc, Linux/uClibc, FreeBSD, OpenSolaris and Windows XP and later
(using MinGW, no full POSIX support). It's also the base library for my GSoC
project this year.

Source Tarball: http://dev.luci.freifunk-halle.net/nixio/nixio-0.3.tar.bz2
Documentation: http://dev.luci.freifunk-halle.net/nixio/doc/

Cheers,
Steven



Changes from version 0.2:
* Added getifaddrs() function.
* Added getsockopt(), setsockopt(), getsockname() and getpeername() directly
to TLS-socket objects unifying the socket interface.
* Added support for CyaSSL as cryptographical backend.
* Added support for x509 certificates in DER format.
* Added support for splice() in UnifiedIO.copyz().
* Added interface to inject chunks into UnifiedIO.linesource() buffer.
* Changed TLS behaviour to explicitely separate servers and clients.
* Fixed usage of signed datatype breaking Base64 decoding.
* Fixed namespace clashes for nixio.fs.
* Fixed splice() support for some exotic C libraries.
* Reconfigure axTLS cryptographical provider and mark it as obsolete.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Phoenix Sol
Holy smokes, this looks awesome. Thanks for sharing, Steven.

( I feel like a kid in a toy store playing with it... )

Phoenix Sol


On Sat, Jul 11, 2009 at 12:50 PM, Steven Barth <[hidden email]> wrote:
Hi Everyone,

I'm happy to announce version 0.3 of nixio, a well-documented multipurpose Lua
library offering system, networking (IPv4, IPv6 and UNIX), I/O (Files, Pipes,
UDP-, TCP-, and TLS-sockets), byte manipulation, hashing and other useful
functionality.

nixio is FOSS under the Apache 2 license and has been successfully compiled
under Linux/glibc, Linux/uClibc, FreeBSD, OpenSolaris and Windows XP and later
(using MinGW, no full POSIX support). It's also the base library for my GSoC
project this year.

Source Tarball: http://dev.luci.freifunk-halle.net/nixio/nixio-0.3.tar.bz2
Documentation: http://dev.luci.freifunk-halle.net/nixio/doc/

Cheers,
Steven



Changes from version 0.2:
* Added getifaddrs() function.
* Added getsockopt(), setsockopt(), getsockname() and getpeername() directly
to TLS-socket objects unifying the socket interface.
* Added support for CyaSSL as cryptographical backend.
* Added support for x509 certificates in DER format.
* Added support for splice() in UnifiedIO.copyz().
* Added interface to inject chunks into UnifiedIO.linesource() buffer.
* Changed TLS behaviour to explicitely separate servers and clients.
* Fixed usage of signed datatype breaking Base64 decoding.
* Fixed namespace clashes for nixio.fs.
* Fixed splice() support for some exotic C libraries.
* Reconfigure axTLS cryptographical provider and mark it as obsolete.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Steven Barth
In reply to this post by Steven Barth
Because I got a few requests by mail a few examples:

File operations:
local nixio = require "nixio", require "nixio.util"
local file = nixio.open("myfile", "w") -- Open myfile for writing
file:writeall("somedata") -- Write some buffer into a file
file:seek(5) -- Seek to offset 5
file:lock("lock", 2) -- Lock 2 bytes beginning from current offset
file:close()

FS operations:
local fs = require "nixio.fs"
for entry in fs.dir("/tmp") do print(entry) end -- Traverse directory
fs.copyr("/tmp", "/tmp/tmp2") -- Recursive copying

Hashing:
local nixio = require "nixio", require "nixio.util"
local newmd5 = nixio.crypto.hash("md5")
newmd5:update("Lorem ipsum")
print((newmd5:update("some stuff"):final()))

Sockets:
local nixio = require "nixio", require "nixio.util"
-- local mysock = nixio.connect("ipv6.google.com", 443) -- IPv6 is supported
local mysock = nixio.connect("google.com", 443) -- Open TCP connection
print(mysock:getpeername())
local mytlssock = nixio.tls("client"):create(mysock) -- TLS context and socket
mytlssock:connect() -- TLS Handshake
mytlssock:writeall("GET / HTTP/1.0\r\n\r\n") -- High-level write
print(mytlssock:read(1024))
mytlssock:close()
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Miles Bader-2
In reply to this post by Steven Barth
Any reason for the duplicating the functionality of luafilesystem,
luasocket, etc ( which AFAICT seem well regarded)?

Thanks,

-Miles

--
Patience, n. A minor form of despair, disguised as a virtue.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

steve donovan
On Mon, Jul 13, 2009 at 10:20 AM, Miles Bader<[hidden email]> wrote:
> Any reason for the duplicating the functionality of luafilesystem,
> luasocket, etc ( which AFAICT seem well regarded)?

I'd second that question.  What stuff does it bring to the table that
isn't covered by existing modules like lfs, lposix, md5, etc?

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Steven Barth
Am Montag 13 Juli 2009 10:20:57 schrieb Miles Bader:
> Any reason for the duplicating the functionality of luafilesystem,
> luasocket, etc ( which AFAICT seem well regarded)?

I understand your points and I really don't want to insult any developer of
the mentioned Lua libraries.
Even before writing nixio I by myself relied mainly on the libraries you
mentioned. They worked fine in most cases and really met my demands for over a
year.
To clarify: I mainly work on embedded devices with 4 or 8 MB of flash so sizes
of libraries really do matter. Everything is being cross-compiled and I have
to take care of the additional Lua libraries for the project working well with
the cross-compile toolchain. So each new library adds an additional
administrative overhead over time.
And as the project evolved the problems I had with the "classic" Lua modules
began to increase, mainly:

luaposix
* It does not cover all POSIX functionality that I need. A co-developer began
writing patches to add functionality. I think at least one of them - the
crypt() function - went back upstream.
* When it comes to third-party developers wanting to join the project - the
lack of documentation was a relatively big problem.
* As we had a cross-plattform project in sight this could be problematic as
well.

lfs
* I used this before switching to luaposix. Works well for what it does. Also
the documentation is good but unfortunately it has a very limited scope. For
the POSIX part I need chmod(), chown(), realpath() and so on.

bitlib
* Autotools for a single C-file?!
* Not possible to cross-compile without doing dirty hacks.

luasocket:
* A really nice piece of software, but:
* I need IPv6 support in the near future.
* What has always bugged me is that a receive() given an amount of bytes to
read always blocked until the whole chunk was available. So when writing
network software - like a JSON-RPC server or client - where the protocol is
not line-based and you don't know how big the request-chunk will be, it was
hard to get the request without fidddling with asynchronous I/O which would be
clearly overkill in this case.
* I need zero-copy-support (sendfile and splice)  -at least on the server-side
which is Linux - to efficiently transfer files from a USB disk attached to an
embedded device over the network.

luasec:
* As I also need TLS support this was the next library I stumbled upon.
Unfortunately it was - besides luaxyssl where xyssl was discontinued for a
longer period - the only one that I found and as I said above if you are
working on embedded devices you are thinking twice about putting the 1MB
openssl monster - even in a compressed form - on your 4MB of flash memory.

So given the overall overhead of maintaining all these third-party libraries
in the buildsystem that cover only 80% or 90% of my demands and then writing
and maintaining patches. I decided to start a new library that has everything
I need for my projects.


Am Montag 13 Juli 2009 10:24:52 schrieb steve donovan:
> I'd second that question.  What stuff does it bring to the table that
> isn't covered by existing modules like lfs, lposix, md5, etc?

To name a few things:
* IPv6 support
* sendfile() support
* Some other misc POSIX features like poll(), nice(), signal(), ...
* TLS and crypto support on top of CyaSSL or axTLS (or OpenSSL)
* A unified I/O interface (read, write, readall, writeall, linesource,
blocksource, sink, copy, ...) for dealing with files, pipes, TCP-sockets and
TLS-sockets the same way.
* Having only ONE library ;-)

Regards
Steven

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

BogdanM
Very nice work. Any change you'll add a good serial port module to this? My Asus WL-500gP kinda needs something like this ... :)

Best,
Bogdan

On Mon, Jul 13, 2009 at 12:30 PM, Steven Barth <[hidden email]> wrote:
Am Montag 13 Juli 2009 10:20:57 schrieb Miles Bader:
> Any reason for the duplicating the functionality of luafilesystem,
> luasocket, etc ( which AFAICT seem well regarded)?

I understand your points and I really don't want to insult any developer of
the mentioned Lua libraries.
Even before writing nixio I by myself relied mainly on the libraries you
mentioned. They worked fine in most cases and really met my demands for over a
year.
To clarify: I mainly work on embedded devices with 4 or 8 MB of flash so sizes
of libraries really do matter. Everything is being cross-compiled and I have
to take care of the additional Lua libraries for the project working well with
the cross-compile toolchain. So each new library adds an additional
administrative overhead over time.
And as the project evolved the problems I had with the "classic" Lua modules
began to increase, mainly:

luaposix
* It does not cover all POSIX functionality that I need. A co-developer began
writing patches to add functionality. I think at least one of them - the
crypt() function - went back upstream.
* When it comes to third-party developers wanting to join the project - the
lack of documentation was a relatively big problem.
* As we had a cross-plattform project in sight this could be problematic as
well.

lfs
* I used this before switching to luaposix. Works well for what it does. Also
the documentation is good but unfortunately it has a very limited scope. For
the POSIX part I need chmod(), chown(), realpath() and so on.

bitlib
* Autotools for a single C-file?!
* Not possible to cross-compile without doing dirty hacks.

luasocket:
* A really nice piece of software, but:
* I need IPv6 support in the near future.
* What has always bugged me is that a receive() given an amount of bytes to
read always blocked until the whole chunk was available. So when writing
network software - like a JSON-RPC server or client - where the protocol is
not line-based and you don't know how big the request-chunk will be, it was
hard to get the request without fidddling with asynchronous I/O which would be
clearly overkill in this case.
* I need zero-copy-support (sendfile and splice)  -at least on the server-side
which is Linux - to efficiently transfer files from a USB disk attached to an
embedded device over the network.

luasec:
* As I also need TLS support this was the next library I stumbled upon.
Unfortunately it was - besides luaxyssl where xyssl was discontinued for a
longer period - the only one that I found and as I said above if you are
working on embedded devices you are thinking twice about putting the 1MB
openssl monster - even in a compressed form - on your 4MB of flash memory.

So given the overall overhead of maintaining all these third-party libraries
in the buildsystem that cover only 80% or 90% of my demands and then writing
and maintaining patches. I decided to start a new library that has everything
I need for my projects.


Am Montag 13 Juli 2009 10:24:52 schrieb steve donovan:
> I'd second that question.  What stuff does it bring to the table that
> isn't covered by existing modules like lfs, lposix, md5, etc?

To name a few things:
* IPv6 support
* sendfile() support
* Some other misc POSIX features like poll(), nice(), signal(), ...
* TLS and crypto support on top of CyaSSL or axTLS (or OpenSSL)
* A unified I/O interface (read, write, readall, writeall, linesource,
blocksource, sink, copy, ...) for dealing with files, pipes, TCP-sockets and
TLS-sockets the same way.
* Having only ONE library ;-)

Regards
Steven


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Miles Bader-2
In reply to this post by Steven Barth
Steven Barth <[hidden email]> writes:
>> Any reason for the duplicating the functionality of luafilesystem,
>> luasocket, etc ( which AFAICT seem well regarded)?
>
> I understand your points and I really don't want to insult any developer of
> the mentioned Lua libraries.
>
> Even before writing nixio I by myself relied mainly on the libraries
> you mentioned. They worked fine in most cases and really met my
> demands for over a year.

Well certainly it's understandable that you may have had problems with
them, needed to cram your desired function set into as small a space as
possible, and wanted to get something out the door quickly, etc.  We've
all been there.

As a community, what do we do now though?  Nixio undoubtedly improves on
the aforementioned libraries in various ways, but it does muddy the
waters a bit, and do-it-all blunder-buss libraries don't seem like a
very good way forward in general.

-Miles

--
Once, adj. Enough.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

steve donovan
On Mon, Jul 13, 2009 at 11:57 AM, Miles Bader<[hidden email]> wrote:
> As a community, what do we do now though?  Nixio undoubtedly improves on
> the aforementioned libraries in various ways, but it does muddy the
> waters a bit, and do-it-all blunder-buss libraries don't seem like a
> very good way forward in general.

It's clear that nixio solves the particular problem very well.
Generally, however, things are in flux.  There was a discussion about
Luiz' proposal for a osex:

http://lua-users.org/lists/lua-l/2009-05/msg00470.html

i.e. answering the question 'what basic cross-platform OS
functionality can we package in a library'?  lfs is cool, but I miss
things like access (which IHMO should be part of lfs), so I go to
lua-ex, but this has an ad-hoc approach to modifying system namespaces
(like os) which feels dirty.  The consensus was that adding things to
os is not necessarily evil, but there should be agreement as to what
extra functions should live here, and what their parameters and return
values should be. For example, os.sleep() is a nice candidate for an
external function, easy to implement on most OSses, but the
specification should be clear on what the meaning of its argument
should be (milliseconds? fractional seconds?)

Another theme of that thread is that it's easy to work at the wrong
level of abstraction when designing such a library, overfocusing on
the platform implementation.  For instance, the lfs pattern of
iterating over entries in a directory is very efficient on POSIX, but
this pattern isn't the most efficient way to do it on Windows if you
then have to stat each filename, since the _find_next function is
actually grabbing more than the file name - so an alternative iterator
over file entries turns out to be needed.

lua-ex is not bad at what it does, it does provide a portable Process
abstraction, etc.  However, it has recently been growing in some
ad-hoc ways; when I was packaging it for Lua for Linux, I found myself
stripping out the new path manipulation functions since they don't
need to be in C and were a bit .. eccentric.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Steven Barth
In reply to this post by Miles Bader-2
Am Montag 13 Juli 2009 11:57:48 schrieb Miles Bader:
> As a community, what do we do now though?  Nixio undoubtedly improves on
> the aforementioned libraries in various ways, but it does muddy the
> waters a bit, and do-it-all blunder-buss libraries don't seem like a
> very good way forward in general.

I think that mainly depends on the way you see and use Lua. If you see it as a
scripting language for bigger applications then you obviously don't need a
standard library with system functions. But if you see Lua as a kind of
lighter alternative to Python you really begin to miss one important thing
that has made Java, Python etc. popular - a good standard library.

I support your statement about do-it-all-libraries when they cover different
high-level functions that aren't related to each other but we are talking
about a basic featureset here, which is simply I/O and bindings to lower-level
c-library functions. The only thing I could see as higher-level story are the
cryptographical parts but thats also nothing that you wouldn't find in the
standard-library of YOUR_HIGHER_LEVEL_LANGUAGE.

> As a community, what do we do now though?
A cooperative competition is something nice to have. We will just see what
happens - in particular - if anyone wants to use nixio in their projects or
not. nixio is just what I wanted to give back to the Lua community after over
one year of using the communities' resources - namely third-party modules.
Nobody should be afraid or upset about a bit of diversity in the Lua module
community ;-)

Have a nice day
Steven





Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

steve donovan
On Mon, Jul 13, 2009 at 12:43 PM, Steven Barth<[hidden email]> wrote:
> Nobody should be afraid or upset about a bit of diversity in the Lua module
> community ;-)

Yes, it's never scared us before ;)

Different tools for different jobs.  This can all feed back into the
the 'standard' modules, e.g. LuaSocket.

I do worry about newcomers to Lua, because it's not clear what to use,
and where to find the best set of batteries. This is where the
distributions come into play.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Petr Štetiar
In reply to this post by BogdanM
Bogdan Marinescu <[hidden email]> [2009-07-13 12:46:11]:

> Very nice work. Any change you'll add a good serial port module to this? My
> Asus WL-500gP kinda needs something like this ... :)

I wrote simple serial port lib. maybe it's what you're looking for. You can
find it at Github[1]. I'm using it on Win32, Windows CE/Mobile and on
Linux/ARM in OpenEmbedded successfully. It's MIT licensed.

1. http://github.com/ynezz/librs232

-- ynezz
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Sam Roberts
In reply to this post by steve donovan
On Mon, Jul 13, 2009 at 3:31 AM, steve donovan<[hidden email]> wrote:
> On Mon, Jul 13, 2009 at 11:57 AM, Miles Bader<[hidden email]> wrote:
> It's clear that nixio solves the particular problem very well.
> Generally, however, things are in flux.  There was a discussion about
> Luiz' proposal for a osex:
>
> http://lua-users.org/lists/lua-l/2009-05/msg00470.html
>
> i.e. answering the question 'what basic cross-platform OS
> functionality can we package in a library'?

People who intend to write cross platform lua code care about the
answer to that, but nxio looks like it goes beyond cross-platform,
which is why I'll be downloading and evaluating it.

A fair amount of reworking of some of the commonly used libraries
involves adding functionality that is not cross-platform, like
sendfile(), or unified integer file and socket descriptors.

Since libraries like lfs are so small, usually a single C file, and
since changes that don't work on Windows can't be accepted upstream,
and maintaining your own version with the same name but extra
functions is annoying (and monkey-patching modules is possibly in bad
taste), it increases pressure to rewrite, or fork and rename.

Examining ruby or python's cross-platform APIs and building up the
same functionality would be useful, but both those languages standard
libraries also include platform specific functionality. Sometimes in a
seperate module, sometimes as API usage warnings.

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

David Manura
In reply to this post by Steven Barth
On Mon, Jul 13, 2009 at 5:30 AM, Steven Barth wrote:
> bitlib
> * Autotools for a single C-file?!
> * Not possible to cross-compile without doing dirty hacks.

Yeah, the fourteenth bit library!  [1]  :)

The docs say, "Can be used as a drop-in replacement for bitlib."  At
least it attempts to reuse the bitlib API, which Lua BitOp also
reuses.  However, there are some differences (e.g. "shl" v.s.
"lshift").

Have you considered Mike's Lua BitOp?  That seems to be the "best
practice" at the moment.

[1] http://lua-users.org/wiki/BitwiseOperators
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Steven Barth
> The docs say, "Can be used as a drop-in replacement for bitlib."  At
> least it attempts to reuse the bitlib API, which Lua BitOp also
> reuses.  However, there are some differences (e.g. "shl" v.s.
> "lshift").
Thanks for pointing that out, it was just a mistake in the documentation. The
library itself uses lshift, rshift, etc. I've fixed it in the online reference.

>
> Have you considered Mike's Lua BitOp?  That seems to be the "best
> practice" at the moment.
I'll put that on the todo for 0.4

Thanks
Steven
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

RJP Computing
In reply to this post by Steven Barth
Sorry for digging this up from so long ago, but another thread got me interested in trying it out.

On Mon, Jul 13, 2009 at 2:17 AM, Steven Barth <[hidden email]> wrote:
Because I got a few requests by mail a few examples:
...
FS operations:
local fs = require "nixio.fs"
for entry in fs.dir("/tmp") do print(entry) end -- Traverse directory

I just tried this on Ubuntu 9.10 and it displays a bunch of the file entries and then just errors out with this:
 
lua: /usr/local/share/lua/5.1/nixio/fs.lua:140: attempt to call a nil value
stack traceback:
/usr/local/share/lua/5.1/nixio/fs.lua:140: in function '_recurse'
/usr/local/share/lua/5.1/nixio/fs.lua:142: in function </usr/local/share/lua/5.1/nixio/fs.lua:129>
(tail call): ?
example.lua:89: in function 'main'
example.lua:105: in main chunk
[C]: ?

Any thoughts. So far from my tests I really like this library and it build very easy on Linux. Now I am going to try to build it for Lua for Windows. More details to follow.
--
Regards,
Ryan
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Phoenix Sol
On Thu, Feb 25, 2010 at 1:58 PM, RJP Computing <[hidden email]> wrote:

lua: /usr/local/share/lua/5.1/nixio/fs.lua:140: attempt to call a nil value
stack traceback:
/usr/local/share/lua/5.1/nixio/fs.lua:140: in function '_recurse'
/usr/local/share/lua/5.1/nixio/fs.lua:142: in function </usr/local/share/lua/5.1/nixio/fs.lua:129>
(tail call): ?
example.lua:89: in function 'main'
example.lua:105: in main chunk
[C]: ?

nixio/lua/nixio/fs.lua:140 looks like this: "for e in nixio.fs.dir(src) do"...
and nixio.fs.dir is a C function from nixio/src/fs.c...

So it looks like you don't have the module loaded properly. Make sure nixio.so is on your Lua C path.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Ryan Pusztai

It is in my Lua C path because. I am using a bunch of other nixio functions,  like sockets and working directory type stuff. I did use "make install" to install the library onto my system. Should I do do something different?
--
Regards,
Ryan

On Feb 25, 2010 3:48 PM, "Phoenix Sol" <[hidden email]> wrote:

On Thu, Feb 25, 2010 at 1:58 PM, RJP Computing <[hidden email]> wrote: > > > lua: /usr/local...

nixio/lua/nixio/fs.lua:140 looks like this: "for e in nixio.fs.dir(src) do"...
and nixio.fs.dir is a C function from nixio/src/fs.c...

So it looks like you don't have the module loaded properly. Make sure nixio.so is on your Lua C path.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Phoenix Sol
On Feb 25, 2010, at 2:56 PM, Ryan Pusztai <[hidden email]> wrote:
> It is in my Lua C path because. I am using a bunch of other nixio  
> functions,  like sockets and working directory type stuff. I did use  
> "make install" to install the library onto my system. Should I do do  
> something different?
>
I dunno, Ryan; "make install" should work fine, if Lua can see your  
shared libs under "/usr/local".

IIRC, with a Lua installed from the Debian/Ubuntu repos, that won't be  
the case.

You could drop nixio.so into your working dir to assert whether this  
is the problem.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] nixio 0.3 - System, Networking and I/O library

Ryan Pusztai
Hi Phoenix,

On Thu, Feb 25, 2010 at 4:13 PM, Phoenix Sol <[hidden email]> wrote:
I dunno, Ryan; "make install" should work fine, if Lua can see your shared libs under "/usr/local".

IIRC, with a Lua installed from the Debian/Ubuntu repos, that won't be the case.

You could drop nixio.so into your working dir to assert whether this is the problem.
 
I did more debugging and it is actually the 
    fs.copyr("/tmp", "/tmp/tmp2") -- Recursive copying
line that is failing. Then I had an idea to run as sudo and it works. So what does that mean?
-- 
Regards,
Ryan
12