Web native scripts (2)
Such of a sysadmin’s life has migrated to the web, so you’ll need a scripting language that has kept pace. We examined both ease of writing our own code, and finding available solutions for doing anything from web interfaces to system stats. What’s noticeable about these languages is the difference in expressiveness and style to produce similar results.
However, this is, once again, secondary to personal preference and local support for many admins. Ruby is quick and enjoyable; Python ‘feels right’ probably due to it being more human readable; newLISP is astonishingly powerful. But these observations remain partisan clichés without a supportive and maintainable environment to use and develop the code for your own networks.
While Bash will be no one’s first choice for a web programming language, it’s good to know that when your server doesn’t provide for your first choice you can fall back on it thanks to bashlib. This a shell script that makes CGI programming in the Bash shell somewhat more tolerable.
Your script will be full of echo statements, interspersed with your commands to produce the desired output. Security considerations mean we wouldn’t recommend running this on the open Internet, but it’s worth bearing in mind that Bash works well as a prototyping language.
It’s easy to fill a text file with comments describing the broad structure that you want, then fill in the gaps – testing snippets interactively and pasting into www.shellcheck.net to check your code as you go. You’ll soon be up and running with a proof of concept.
Code Patterns, by NewLISP creator Lutz Mueller, is available on the www.newlisp.org website and has chapters on HTTPD and CGI, as well as TCP/IP and UDP communications. If you add in the section on controlling applications, and you’ll have everything to get you started.
NewLISP’s built-in networking, and simple (or lack of) syntax, makes it surprisingly easy to generate HTML pages of results from, for instance, your monitoring scripts. For a ready built framework, newLISP on Rockets – which uses Bootstrap, jQuery and SQLite – combines rapid application development with good performance. NewLISP on Rockets provides several functions, from (convert-json- to-list) via (twitter-search) to (display-post-box), which will help you add web functionality.
We’re impressed but we remain concerned by the small size of the community and the intermittent pace of development.
Perl was the first web CGI scripting language and has more or less kept pace with the times. It certainly has the libraries, and enough examples to learn from, but with no dominant solution you’ll have to pick carefully. Catalyst, Dancer, and Mojolicious are all good web application frameworks.
More likely you’ll find everything you need in CPAN. You can glue together a few of the libraries – many of which are already collected together in distros – to handle a pipeline of tasks, such as retrieving XML data, converting the data to PDF files and indexing it on a web page.
Perl’s traditional CGI interface is still available, and despite better performing alternatives abstracted through PSGI, you may find that use CGI; is all you need to web-enable your script, and remember: ‘there’s always more than one way to do it’.
Python’s Web Server Gateway Interface (WSGI), which was defined in PEP 333, abstracts away the web server interface, while WSGI libraries deal with session management, authentication and almost any other problem you’d wish to be tackled by middleware.
Python also has plenty of full- stack web frameworks, such as Django, TurboGears and Pylons. Like Rails, for some purposes you may be better off coding web functionality onto an existing script. But Python’s template engines will save you from generating a mess of mixed HTML and Python.
Python has many other advantages, from the Google App Engine cloud with its own Python interpreter, which works with any WSGI- compatible web application framework, for testing of scalable applications to supporting a clean style of metaprogramming.
Don’t imagine for one moment that Rails is a panacea for most sysadmin problems. It’s not. And while Sinatra certainly makes it easy to roll out anything web-based in Ruby, even this is overkill for most purposes.
That said, Rails does a good job of getting code up quickly and just doesn’t drown in all that magic, generated code. Ruby is ideal for getting any script web-enabled, thanks to gems that are written by thoughtful people who have made sane decisions.
Putting a web interface on our backup script, for example, was fun, but distracting as we played with several gems, eg to export reports to Google spreadsheets. Tools like nanoc , which generate static HTML from HAML, and some of the reporting gems complement the language’s expressiveness, and make adding any functionality to scripts a breeze.