Skeleton Week: Nopaste with mojopaste
The nopaste utility from the venerable ETHER is a terrific addition to your standard deployment. Installation is trivial with:
This simple utility makes it trivial to send text data to your pastebin-like service of choice. The core distribution includes a half dozen services, and divers others have been published by other authors on the CPAN. Chances are your favorite is already supported - if not then you've found yourself a skeleton week project.
List what's available on the system already with:
With a fresh install from the CPAN, there are a few public services that will work without any log in. One such service is the Debian paste service. Let's paste some random lipsum text as an example (this should be fairly platform agnostic):
curl -s -X POST https://lipsum.com/feed/json |\
jq -r '.feed.lipsum' |\
nopaste --services Debian
Nopaste will try each available service in turn (unless specified) until it succeeds in saving our text somewhere. In the above example I have specified just the Debian service via the --services|-s option to move things along, which could alternatively be the NOPASTE_SERVICES environment variable. A comma list can be provided via either to specify more than one option.
The url of this paste will be printed to your command line for your reference and confirming success. The --open|-o option will instead, attempt to open the url in your web browser of choice. The --copy|-x option will place the url in to your clipboard (if the Clipboard module is installed).
Some services may require credentials. The Gist service for example, requires either an Oauth token or your Github user+password. The pod describe how to provide these.
In the event that you decide to install Nopaste on your systems, and you have a sensible security policy of not allowing them HTTP access random internet hosts, you may like to install a simply pastebin-like service in your private network.
This brings us to Mojopaste written and maintained by JHTHORSEN. This software is also available on the CPAN, and as the name implies is built upon Mojolicious framework.
Install via cpanm, then run standalone:
mojopaste daemon \
The POD describes all available options, and further steps to use a configuration file rather than using cli and environment variables.
An "official" Docker image is available.
Though not documented, if you install Mojopaste to use your system perl, it's easy to make Mojopaste run in an Apache VirtualHost as follows:
PerlSetVar psgi_app /usr/bin/mojopaste
# Where mojopaste stores its files
PerlSetEnv PASTE_DIR /srv/mojopaste/
# 'deployment' is 'production' for plack, which tells it to turn off debugging stuff
PerlSetEnv PLACK_ENV deployment
# mojo's home dir
PerlSetEnv MOJO_HOME /srv/mojopaste/
Co-locating this service on an existing internal Wiki server makes sense to me as the content is just as sensitive, and is what I have done historically for $clients. It may also save you adjusting firewall rules and be simple to add to your back up systems. Paste data is fairly minimal so is unlikely to need more space than what already is spare on your Wiki server.
If you would like your pastes to expire, a simple approach is to have a cron job that removes them. The pastes are stored as individual files so they can be easily removed using filesystem tools. Here is a line that will do the trick, adjust to suit your tastes:
30 * * * * root find /srv/mojopaste -ctime 60 -delete
With your Mojopaste installed and configured. We can refer again to Nopaste which has a Mojopaste plugin as part of the core plugins.
We can use Nopaste with our Mojopaste install as follows:
cat /proc/cpuinfo | nopaste
The two exports can be moved to your shell's profile or rc files, deployed via your deployment system, and forgotten about. The nopaste will then "just work" whenever you need to save something from logs, proc files, etc.
A few years on I have a few extra thoughts.
Firstly, an internal pastebin for your company really is vital. Pasting from your work computer to a public pastebin is almost certainly a violation of employment non-disclosure agreement regardless of the content. Even if you disagree, getting in to the habit may lead to accidents like pasting customer data, passwords, keys etc.
Secondly, I would consider the above to be the minimum viable product for an internal pastebin. Some additional steps would be needed to productionize it.
Because the pastebin will sooner or later have sensitive data posted to it, at a minimum you should ensure it's connected to your company's single sign on (which it has right? Check out LemonLDAP::NG). This means that if it is exposed to the internet accidentally it wont be open to anyone (ymmv).
Mojopaste is built on mojolicious so you shouldn't have any problems using a Plack middleware or putting a reverse proxy in front of it to provide the feature.
Unfortunately Mojopaste doesn't have access controls for individual content items so anyone in your company can view anything that is pasted. That may be a feature you can add but I understand that the scope of mojopaste is intentionally simple.
Similarly, anyone with access to the server or its unencrypted backups can view any of the content.
You may also want to put some content filters in place to block or flag sensitive content like credit cards, phone numbers, social security numbers, private keys etc