c0d3 :: j0rg3

A collection of tips, tricks and snips. A proud Blosxom weblog. All code. No cruft.

Sun, 19 Feb 2017

Privacy: perspective and primer.

Hello friends.

While the overall telos of this blog is to, generally speaking, convey code snippets and inspire the personal projects of others, today we’re going to do something a smidgeon different.

This will be a layman’s look at varied dimensions of information security from a comfortable distance. Over the years, I’ve secured servers, operating systems, medical data, networks, communications and I’ve unsecured many of these same things. The topics are too sprawling to be covered in a quick summary — but let’s find a point of entry.

Those of us who are passionate about information security are well aware of how daunting is the situation. For newcomers, it sometimes seems rather impossible. Pick any subject and there are probably well-informed and convincing experts in diametric equidistance from any “happy medium”.

Let’s imagine that (like most of us) you don’t have anything spectacular to protect. However, you dislike the idea of our ever-dissolving privacy. Therefore you want to encrypt communications. Maybe you begin to use Signal. However, there are criticisms that there is a “backdoor” (there is not). Further, there are accusations that open source projects are coded by those who can’t get real jobs. Conversely, open source projects are widely open for peer review. If it worries one enough they are free to review code themselves.

PGP can encrypt content but concerns surround algorithmic selections. Some are worried about metadata crumbs. Of course, there’s nothing preventing the frequent switching of keys and email addresses. You could use BitMessage, any number of chat solutions or drop at paste bins.

Let’s leave those concerns aside for when you’ve figured out what you’re intending to protect. These arguments surround any subject in information security and we’re not going to investigate them on a case by case basis. Least, not in this post.

At the coarsest granularity, the question is analogous to the practicality of locking your doors or sealing your post envelopes. Should I take measures toward privacy?

My opinion is rather predictable: of course you should!

There’s a very pragmatic explanation. If there ever comes a day when you should like to communicate privately, that’s a terrible time to start learning.

Take the easy road and start using some of the myriad tools and services available.

Should you decide to take InfoSec seriously, you’ll need to define a threat model.
That is: What am I protecting? From whom am I protecting? (e.g. what are probable attack vectors?)

That’s where you need to make choices about trusting products, protocols, methods, algorithms, companies, servers, et cet. Those are all exciting subjects to explore but all too often brushing up against them can be exasperating and cause premature burn-out.

That in mind, let’s employ the philosophy that any effort toward security is better than none and take a look at a few points where one might get wetted-toes.

If you have questions or want specific advice, there are several ways below to initiate a secure conversation with me.


Secure your browser:

  • Privacy Badger: Block tracking
  • HTTPS Everywhere: Increase your encryptioning
  • uBlock: Advertisements are for others

    Secure communications:

  • Mailvelope: PGP email encryption for your major webmail provider (e.g., Gmail) | contact | pubkey
  • Tutanota: Encrypted webmail | Kontakt
  • Protonmail: Well-established provider of PGP encrypted webmail, featuring 2FA | kontakta
  • BitMessage: P2P encrypted communications protocol | contact: BM-2D9tDkYEJSTnEkGDKf7xYA5rUj2ihETxVR | Bitmessage channel list
  •   [ Bitmessage in a Docker container ]

  • BitMessage.ch: BitMessage email gateway | contact
  • BitMsg.me: Online BitMessage service
  • Keybase.io: Keybase maps your identity to your public keys, and vice versa
  • Signal: PGP encrypted TXT messages
  • Wire: Encrypted chat, video and calls
  • RIOT: Open-source, IRC-based, Matrix; run your own server
  • Wickr: Encrypted ephemeral chat
  •   [ n.b. Wickr’s .deb package seeks a unicode library (libicu52) which is not available to a recent Kali (or anything) install; .deb file is based on Ubuntu’s 2014 LTS release. Wickr in a Docker container ]


    Explore alternate nets (e.g., Deep Web, Dark Net):

  • MaidSafe: Promising new alt-web project
  • Qubes: a reasonably secure operating system
  • FreeNet: Alt-net based primarily on already knowing with whom you intend to collaborate
  • Bitmask: VPN solution to anonymize your traffic
  • TAILS: A live operating system based on the Tor network
  • TorBrowser: Stand-alone browser for Tor (less secure than TAILS)
  • Whonix: the most secure (and complex) way to access the Tor network
  • i2p: an other approach to creating a secure and private alternate web
  • Morph.is: fun alt-net, aimed at producing The World Brain. Although, it’s future looks a lot less promising since the lead dev was killed.
  • ZeroNet: one more encrypted anonymous net
  • Have fun and compute safely!

    Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
    Permalink: 20170219.privacy.prespective.primer

    Sat, 18 Feb 2017

    The making of a Docker: Part II - Wickr: with bonus analysis

    Recently, I read a rather excited attention-catching piece about how Wickr is the super-secure version of Slack. Attention caught in part because I feel like Wickr has been around for a while. I’d not seen anyone raving about its security in places where I normally interact with those who are highly informed about such subjects.

    Good is that it seems the folk at Wickr did a fine job of making sure valuable data aren’t left behind.
    The bad: closed-source, not subject to independent review; crazy marketin’-fancy-talk without a thorough description of how it does what is claimed.
    Any time I’m looking at a product or service that boasts security, I sort of expect to see a threat model.

    [ Update: At the time I was working on this project, the folk at Wickr were, evidently, opening their source. That’s spectacular news! Check it out on Github. ]

    This began as an exercise to provide another piece of security-ish software in a Docker container. Anyone who has used a live distro (e.g., Kali, TAILS) with any regularity knows the ritual of installing favorite tools at each boot, data stores on removable media.

    For me, there is tremendous appeal in reducing that to something like:
    git clone https://georgeglarson/wickr
    cd docker-wickr

    Let’s dig in!

    Having created a number of Docker containers my workflow is to queue up the base OS and go through the steps needed to get the software running while keeping careful notes. In this case, I had originally tried to install Wickr on a current copy of Kali. It was already known that Wickr, based off of Ubuntu 14.04, needed an older unicode library. So we begin with Ubuntu 14.04.

    Grab a copy of Wickr and see what’s required:
    dpkg -I wickr-me_2.6.0_amd64.deb

    new debian package, version 2.0.
    size 78890218 bytes: control archive=4813 bytes.
    558 bytes, 14 lines control
    558 bytes, 14 lines control64
    10808 bytes, 140 lines md5sums
    Package: wickr-me
    Architecture: amd64
    Section: net
    Priority: optional
    Version: 2.6.0-4
    Replaces: wickr
    Conflicts: wickr
    Depends: libsqlcipher0, libuuid1, libicu52, libavutil52|libavutil54, libc6, libssl1.0.0, libx264-142, libglib2.0-0, libpulse0, libxrender1, libgl1-mesa-glx
    Recommends: libnotify-bin, gstreamer-plugins0.10-good, gstreamer-plugins0.10-bad, gstreamer-plugins0.10-ugly
    Maintainer: Wickr Inc.
    Installed-Size: 200000
    Description: Secure Internet Chat and Media Exchange agent
    Wickr is a secure communications client

    Okay. The CLI should do most of the work for us, giving a formatted list of dependencies.
    dpkg -I wickr-me_2.6.0_amd64.deb | grep -E "^ Depends: | Recommends: " | sed -e "s/ Depends: //" -e "s/ Recommends: //" -e "s/,//g" -e "s/ / \\\ \n/g"

    libsqlcipher0 \
    libuuid1 \
    libicu52 \
    libavutil54 \
    libc6 \
    libssl1.0.0 \
    libx264-142 \
    libglib2.0-0 \
    libpulse0 \
    libxrender1 \
    libnotify-bin \
    gstreamer-plugins0.10-good \
    gstreamer-plugins0.10-bad \
    gstreamer-plugins0.10-ugly \

    Attempting to get those with apt-get reports that it cannot find the gstreamer bits.

    Let’s find:
    apt-cache search gstreamer | grep -i plugin | grep -E "good|bad|ugly"

    gstreamer0.10-plugins-good - GStreamer plugins from the "good" set
    gstreamer0.10-plugins-bad - GStreamer plugins from the "bad" set
    gstreamer0.10-plugins-ugly - GStreamer plugins from the "ugly" set

    So, there’s the format we need to get the gstreamer dependencies. We know that we’ll also want SSH and wget. That should be enough for our Dockerfile.

    We’ll pull down Wickr:
    wget https://dls.wickr.com/Downloads/wickr-me_2.6.0_amd64.deb

    Then install:
    dpkg -i wickr-me_2.6.0_amd64.deb

    Okay! We are, in theory, ready to run Wickr. We’re about to see we aren’t yet there — but these sorts of problems are pretty commonplace.

    wickr-me: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory

    Huh! We need libxslt. Let’s fix that: apt-get install libxslt1-dev

    Now we can run it.

    This application failed to start because it could not find or load the Qt platform plugin "xcb".

    Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

    Reinstalling the application may fix this problem.
    Aborted (core dumped)

    One more: apt-get install xcb

    Okay. That really was the last one. Now we have a complete list of dependencies for our Dockerfile:
    RUN apt-get update && apt-get install -y \
    gstreamer0.10-plugins-good \
    gstreamer0.10-plugins-bad \
    gstreamer0.10-plugins-ugly \
    libsqlcipher0 \
    libuuid1 \
    libicu52 \
    libavutil52 \
    libc6 \
    libssl1.0.0 \
    libx264-142 \
    libglib2.0-0 \
    libpulse0 \
    libxrender1 \
    libxslt1-dev \
    libgl1-mesa-glx \
    libnotify-bin \
    ssh \
    wget \
    xcb \
    && apt-get clean \

    We now have Wickr in a Docker container and, because we are the curious sort, need to peek into what’s happening.

    A natural first step is to set Wireshark atop Wickr. At a glance, seems to be communicating with a single IP address ( via HTTPS.

    Unsurprsingly, the client communicates to the server whenever a message is sent. Further it appears to poll the same address periodically asking for new messages. We see that the address resolves to Rackspace in San Antonio, TX.

    We can easily establish the link between this IP address, Rackspace and the application.

    Well, that’s enough. Right?




    We’re still a little curious.

    Aren’t we?

    I mean, what’s the big question here? What happens if there’s a man in the middle? Persons so eagerly connect to any free WIFI, it is clearly a plausible scenario. Well… One way to find out!

    Here’s what we learned. Server-side, the application is written in PHP. The IP address is resolved by the URI ‘secex.info’.

    When we send, it calls ‘postMessage.php’:

    When we receive, ‘downloadMessage.php’:

    And it calls ‘newMessageCheck.php’ to, y’know, check for new messages.

    Other analyses have forensically examined artefacts left behind; there are published descriptions of the encryption methods used for the local database connection. We didn’t go into more aggressive efforts such as disassembly because we are too lazy for that jazz!

    My opinion, we didn’t learn anything wildly unexpected. Overall, Wickr seems an okay solution for convenient encrypted messaging. That’s always the trade: convenience vs. security. Least we ended with a Docker container for the software!

    Github | Docker

    Tags: , , ,
    Permalink: 20170218.making.a.docker.wickr

    Fri, 17 Feb 2017

    The making of a Docker: Part I - Bitmessage GUI with SSH X forwarding

    Lately, I’ve been doing a lot of work from a laptop running Kali. Engaged in pursuit of a new job, I’m brushing up on some old tools and skills, exploring some bits that have changed.

    My primary desktop rig is currently running Arch because I love the fine grain control and the aggressive releases. Over the years, I’ve Gentoo’d and Slacked, Crunchbanged, BSD’d, Solarised, et cet. And I’ve a fondness for all of them, especially the security-minded focus of OpenBSD. But, these days we’re usually on Arch or Kali. Initially, I went with Black Arch on the laptop but I felt the things and ways I was fixing things were too specific to my situation to be good material for posts.

    Anyway, I wanted to get Bitmessage running, corresponding to another post I have in drafts. On Kali, it wasn’t going well so I put it on the Arch box and just ran it over the network. A reasonable solution if you’re in my house but also the sort of solution that will keep a hacker up at night.

    If you’re lucky, there’s someone maintaining a package for the piece of software that you want to run. However, that’s often not the case.

    If I correctly recall, to “fix” the problem with Bitmessage on Kali would’ve required the manual installation an older version of libraries that were already present. Those libraries should, in fact, be all ebony and ivory, living together in harmony. However, I just didn’t love the idea of that solution. I wanted to find an approach that would be useful on a broader scale.

    Enter containerization/virtualization!

    Wanting the lightest solution, I quickly went to Docker and realized something. I have not before built a Docker container for a GUI application. And Bitmessage’s CLI/daemon mode doesn’t provide the fluid UX that I wanted. Well, the easy way to get a GUI out of a Docker container is to forward DISPLAY as an evironment variable (i.e., docker run -e DISPLAY=$DISPLAY). Splendid!

    Except that it doesn’t work on current Kali which is using QT4. There’s a when graphical apps are run as root and though it is fixed in QT5, we are using current Kali. And that means we are, by default, uid 0 and QT4.

    I saw a bunch of workarounds that seemed to have spotty (at best) rates of success including seting QT’s graphics system to Native and giving Xorg over to root. They, mostly, seemed to be cargo cult solutions.

    What made the most sense to my (generally questionable) mind was to use X forwarding. Since I had already been running Bitmessage over X forwarding from my Arch box, I knew it should work just the same.

    To be completely truthful, the first pass I took at this was with Vagrant mostly because it’s SO easy. Bring up your Vagrant Box and then:
    vagrant ssh -- -X

    Having proof of concept, I wanted a Docker container. The reason for this is practical. Vagrant, while completely awesome, has substantially more overhead than Docker by virtualizing the kernel. We don’t want a separate kernel running for each application. Therefore Docker is the better choice for this project.

    Also, we want this whole thing to be seemless. We want to run the command bitmessage and it should fire up with minimal awkwardness and hopefully no extra steps. That is we do not want to run the Docker container then SSH into it and execute Bitmessage as individual steps. Even though that’s going to be how we begin.

    The Bitmessage wiki accurately describes how to install the software so we’ll focus on the SSH setup. Though when we build the Dockerfile we will need to add SSH to the list from the wiki.

    We’re going to want the container to start so that the SSH daemon is ready. Until then we can’t SSH (with X forwarding) into the container. Then we’ll want to use SSH to kick off the Bitmessage application, drawing the graphical interface using our host system’s X11.

    We’re going to take advantage of Docker’s -v --volume option which allows us to specify a directory on our host system to be mounted inside our container. Using this feature, we’ll generate our SSH keys on the host and make them automatically available inside the container. We’ll tuck the keys inside the directory that Bitmessage uses for storing its configuration and data. That way Bitmessage’s configuration and stored messages can be persistent between runs — and all of your pieces are kept in a single place.

    When we generate the container /etc/ssh/sshd_config is configured to allow root login without password only (i.e., using keys). So here’s how we’ll get this done:
    mkdir -p ~/.config/PyBitmessage/keys #Ensure that our data directories exist
    cd ~/.config/PyBitmessage/keys
    ssh-keygen -b 4096 -P "" -C $"$(whoami)@$(hostname)-$(date -I)" -f docker-bitmessage-keys #Generate our SSH keys
    ln -fs docker-bitmessage-keys.pub authorized_keys #for container to see pubkey

    Build our container (sources available at Github and Docker) and we’ll make the script to handle Bitmessage to our preferences. #!/bin/bash
    # filename: bitmessage
    set -euxo pipefail

    # open Docker container:
    # port 8444 available, sharing local directories for SSH and Bitmessage data
    # detatched, interactive, pseudo-tty (-dit)
    # record container ID in $DID (Docker ID)
    DID=$(docker run -p 8444:8444 -v ~/.config/PyBitmessage/:/root/.config/PyBitmessage -v ~/.config/PyBitmessage/keys/:/root/.ssh/ -dit j0rg3/bitmessage-gui bash)

    # find IP address of new container, record in $DIP (Docker IP)
    DIP=$(docker inspect $DID | grep IPAddress | cut -d '"' -f 4)

    # pause for one second to allow container's SSHD to come online
    sleep 1

    # SSH into container and execute Bitmessage
    ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oIdentityFile=~/.config/PyBitmessage/keys/docker-bitmessage-keys -X $DIP ./PyBitmessage/src/bitmessagemain.py

    # close container if Bitmessage is closed
    docker kill $DID

    Okay, let’s make it executable: chmod +x bitmessage

    Put a link to it where it can be picked up system-wide: ln -fs ~/docker-bitmessage/bitmessage /usr/local/bin/bitmessage

    There we have it! We now have a functional Bitmessage inside a Docker container. \o/

    In a future post we’ll look at using eCryptfs to further protect our Bitmessage data stores.

      Project files: Github and Docker

    Tags: , , , , , , , , , , ,
    Permalink: 20170217.making.a.docker.bitmessage

    Mon, 17 Feb 2014

    Installing INN’s Project Largo in a Docker containter

    Prereqruisites: Docker, Git, SSHFS.

    Today we’re going to look at using Docker to create a WordPress installation with the Project Largo parent theme and a child theme stub for us to play with.

    Hart Hoover has established an image for getting a WordPress installation up and running using Docker. For whatever reason, it didn’t work for me out-of-box but we’re going to use his work to get started.

    Let’s make a place to work and move into that directory:
    cd ~
    mkdir project.largo.wordpress.docker
    cd project.largo.wordpress.docker

    We’ll clone the Docker/Wordpress project. For me, it couldn’t untar the latest WordPress. So we’ll download it outside the container, untar it and modify the Dockerfile to simply pull in a copy:
    git clone https://github.com/hhoover/docker-wordpress.git
    cd docker-wordpress/
    wget http://wordpress.org/latest.tar.gz
    tar xvf latest.tar.gz
    sed -i 's/ADD http:\/\/wordpress.org\/latest.tar.gz \/wordpress.tar.gz/ADD \.\/wordpress \/wordpress/' Dockerfile
    sed -i '/RUN tar xvzf \/wordpress\.tar\.gz/d' Dockerfile

    Then, build the project which may take some time.
    sudo docker build -t $ME/wordpress .

    If you’ve not the images ready for Docker, the process should begin with something like:
    Step 0 : FROM boxcar/raring
    Pulling repository boxcar/raring
    32737f8072d0: Downloading [> ] 2.228 MB/149.7 MB 12m29s

    And end something like:
    Step 20 : CMD ["/bin/bash", "/start.sh"]
    ---> Running in db53e215e2fc
    ---> 3f3f6489c700
    Successfully built 3f3f6489c700

    Once the project is built, we will start it and forward ports from the container to the host system, so that the Docker container’s site can be accessed through port 8000 of the host system. So, if you want to see it from the computer that you’ve installed it on, you could go to ‘HTTP://’. Alternatively, if your host system is already running a webserver, we could use SSHFS to mount the container’s files within the web-space of the host system.

    In this example, however, we’ll just forward the ports and mount the project locally (using SSHFS) so we can easily edit the files perhaps using a graphical IDE such as NetBeans or Eclipse.

    Okay, time to start our Docker image and find its IP address (so we can mount its files):
    DID=$(docker run -p 8000:80 -d $ME/wordpress)
    DIP=$(docker inspect $DID | grep IPAddress | cut -d '"' -f 4)
    docker logs $DID| grep 'ssh user password:' --color

    Copy the SSH password and we will make a local directory to access the WordPress installation of our containter.
    cd ~
    mkdir largo.mount.from.docker.container
    sshfs user@$DIP:/var/www $HOME/largo.mount.from.docker.container
    cd largo.mount.from.docker.container
    PROJECT=$(pwd -P)

    Now, we can visit the WordPress installation and finish setting up. From the host machine, it should be ‘HTTP://’. There you can configure Title, Username, Password, et cet. and finish installing WordPress.

    Now, let’s get us some Largo! Since this is a test project, we’ll sacrifice security to make things easy. Our Docker WordPress site isn’t ready for us to easily install the Largo parent theme, so we’ll make the web directory writable by everybody. Generally, this is not a practice I would condone. It’s okay while we’re experimenting but permissions are very important on live systems!

    Lastly, we’ll download and install Largo and the Largo child theme stub.
    ssh user@$DIP 'sudo chmod -R 777 /var/www'
    wget https://github.com/INN/Largo/archive/master.zip -O $PROJECT/wp-content/themes/largo.zip
    unzip $PROJECT/wp-content/themes/largo.zip -d $PROJECT/wp-content/themes/
    mv $PROJECT/wp-content/themes/Largo-master $PROJECT/wp-content/themes/largo
    wget http://largoproject.wpengine.netdna-cdn.com/wp-content/uploads/2012/08/largo-child.zip -O $PROJECT/wp-content/themes/largo-child.zip
    unzip $PROJECT/wp-content/themes/largo-child.zip -d $PROJECT/wp-content/themes
    rm -rf $PROJECT/wp-content/themes/__MACOSX/

    We are now ready to customize our Project Largo child theme!

    Tags: , , , , , ,
    Permalink: 20140217.project.largo.docker

    Thu, 13 Jun 2013

    Blogitechture continued… Simplify with Vim

    Last we were discussing the structure and design of your own CLI-centric blog platform, we had some crude methods of starting and resuming posts before publishing.

    Today, let’s explore a little more into setting up a bloging-friendly environment because we need to either make the experience of blogging easy or we’ll grow tired of the hassle and lose interest.

    We can reasonably anticipate that we won’t want to beleaguered with repetitious typing of HTML bits. If we’re going to apply paragraph tags, hyperlinks, codeblocks, etc. with any frequency, that task is best to be simplified. Using Vim as our preferred editor, we will use Tim Pope’s brilliant plug-ins ‘surround’ and ‘repeat’, combined with abbreviations to take away the tedium.

    The plug-ins just need dropped into your Vim plugin directory (~/.vim/plugin/). The directory may not exist if you don’t have any plug-ins yet. That’s no problem, though. Let’s grab the plugins:

    cd ~/.vim/
    wget "http://www.vim.org/scripts/download_script.php?src_id=19287" -O surround.zip
    wget "http://www.vim.org/scripts/download_script.php?src_id=19285" -O repeat.zip

    Expand the archives into the appropriate directories:

    unzip surround.zip
    unzip repeat.zip

    Ta-da! Your Vim is now configured to quickly wrap (surround) in any variety of markup. When working on a blog, you might use <p> tags a lot by putting your cursor amid the paragraph and typing yss<p>. The plug-in will wrap it with opening and closing paragraph tags. Move to your next paragraph and then press . to repeat.

    That out of the way, let’s take advantage of Vim’s abbreviations for some customization. In our .vimrc file, we can define a few characters that Vim will expand according to their definition. For example, you might use:
    ab <gclb> <code class="prettyprint lang-bsh linenums:1">
    Then, any time you type <gclb> and bress <enter>, you’ll get:
    <code class="prettyprint lang-bsh linenums:1">

    The next time that we take a look at blogitecture, we will focus on making the posts convenient to manage from our CLI.

    Tags: , , , ,
    Permalink: 20130613.blogitechture.continued

    Thu, 23 May 2013

    GNU Screen: Roll your own system monitor

    Working on remote servers, some tools are practically ubiquitous — while others are harder to come by. Even if you’ve the authority to install your preferred tools on every server you visit, it’s not always something you want to do. If you’ve hopped on to a friend’s server just to troubleshoot a problem, there is little reason to install tools that your friend is not in the habit of using. Some servers, for security reasons, are very tightly locked down to include only a core set of tools, to complicate the job of any prying intruders. Or perhaps it is a machine that you normally use through a graphical interface but on this occasion you need to work from the CLI.

    These are very compelling reasons to get comfortable, at the very least, with tools like Vim, mail, grep and sed. Eventually, you’re likely to encounter a situation where only the classic tools are available. If you aren’t competent with those tools, you’ll end up facing the obstacle of how to get files from the server to your local environment where you can work and, subsequently, how to get the files back when you’re done. In a secured environment, this may not be possible without violating protocols.

    Let’s take a look at how we can build a makeshift system monitor using some common tools. This particular configuration is for a server running PHP, MySQL and has the tools Htop and mytop installed. These can easily be replaced with top and a small script to SHOW FULL PROCESSLIST, if needed. The point here is illustrative, to provide a template to be modified according to each specific environment.

    (Note: I generally prefer tmux to Gnu Screen but screen is the tool more likely to be already installed, so we’ll use it for this example.)

    We’re going to make a set of windows, by a configuration file, to help us keep tabs on what is happening in this system. In so doing, we’ll be using the well-known tools less and watch. More specifically, less +F which tells less to “scroll forward”. Other words, less will continue to read the file making sure any new lines are added to the display. You can exit this mode with CTRL+c, search the file (/), quit(q) or get back into scroll-forward mode with another uppercase F.

    Using watch, we’ll include the “-d” flag which tells watch we want to highlight any changes (differences).

    We will create a configuration file for screen by typing:

    > vim monitor.screenrc

    In the file, paste the following:

    # Screen setup for system monitoring
    # screen -c monitor.screenrc
    hardstatus alwayslastline
    hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]'

    screen -t htop 0 htop
    screen -t mem 1 watch -d "free -t -m"
    screen -t mpstat 2 watch -d "mpstat -A"
    screen -t iostat 3 watch -d "iostat"
    screen -t w 4 watch -d "w"
    screen -t messages 5 less +F /var/log/messages
    screen -t warn 6 less +F /var/log/warn
    screen -t database 7 less +F /srv/www/log/db_error
    screen -t mytop 8 mytop
    screen -t php 9 less +F /srv/www/log/php_error

    (Note: -t sets the title, then the window number, followed by the command running in that window)

    Save the file (:wq) or, if you’d prefer, you can grab a copy by right-clicking and saving this file.

    Then we will execute screen using this configuration, as noted in the comment:

    > screen -c monitor.screenrc

    Then you can switch between windows using CTRL+a, n (next) or CTRL+a, p (previous).

    I use this technique on my own computers, running in a TTY different from the one used by X. If the graphical interface should get flaky, I can simply switch to that TTY (e.g., CTRL+ALT+F5) to see what things are going on — and take corrective actions, if needed.

    Tags: , , , , , , , , , ,
    Permalink: 20130523.gnu.screen.system.monitor

    Wed, 08 May 2013

    Deleting backup files left behind by Vim

    It’s generally a great idea to have Vim keep backups. Once in awhile, they can really save your bacon.

    The other side of that coin, though, is that they can get left behind here and there, eventually causing aggravation.

    Here’s a snippet to find and eliminate those files from the current directory down:

    find ./ -name '*~' -exec rm '{}' \; -print -or -name ".*~" -exec rm {} \; -print
    This uses find from the current directory down (./) to execute an rm statement on all files with an extension ending in tilde (~)
    Alternatively, you could just store your backups elsewhere. In Vim, use :help backupdir for more information.

    Tags: , , , ,
    Permalink: 20130508.delete.vim.backups

    Tue, 07 May 2013

    Welcome, traveler.

    Thanks for visiting my little spot on the web. This is a Blosxom ‘blog which, for those who don’t know, is a CGI written in Perl using the file-system (rather than a database).

    To the CLI-addicted, this is an awesome little product. Accepting, of course, that you’re going to get under the hood if you’re going to make it the product you want. After some modules and hacking, I’m pleased with the result.

    My posts are just text files, meaning I start a new one like: vim ~posts/`date +%Y%m%d`.brief.subject.txt

    Note: the back-ticks (`) tell the system that you want to execute the command between ticks, and dynamically insert its output into the command. In this case, the command date with these parameters:
    1. (+) we’re going to specify a format
    2. (%Y) four-digit year
    3. (%m) two-digit month
    4. (%d) two-digit day
    That means the command above will use Vim to edit a text file named ‘20130507.brief.subject.txt’ in the directory I have assigned to the hash of ‘posts’. (using hash this way is a function of Zsh that I’ll cover in another post)

    In my CLI-oriented ‘blog, I can sprinkle in my own HTML or use common notation like wrapping a word in underscores to have it underlined, forward-slashes for italics and asterisks for bold.

    Toss in a line that identifies tags and, since Perl is the beast of Regex, we pick up the tags and make them links, meta-tags, etc.

    Things here are likely to change a lot at first, while I twiddle with CSS and hack away at making a Blosxom that perfectly fits my tastes — so don’t be too alarmed if you visit and things look a tad wonky. It just means that I’m tinkering.

    Once the saw-horses have been tucked away, I’m going to take the various notes I’ve made during my years in IT and write them out, in a very simple breakdown, aimed at sharing these with people who know little about how to negotiate the command line. The assumption here is that you have an interest in *nix/BSD. If you’ve that and the CLI is not a major part of your computing experience, it probably will be at some point. If you’re working on systems remotely, graphical interfaces often just impede you.

    Once you’ve started working on remote machines, the rest is inevitable. You can either remember how to do everything two ways, through a graphical interface and CLI — or just start using the CLI for everything.

    So let’s take a little journey through the kinds of things that make me love the CLI.

    Tags: , , , , , , , , ,
    Permalink: 20130507.greetings