Look Below





  • Linux Bare Metal Disaster Recovery on USB

    Linux Bare Metal Disaster Reco...



     As an added layer to successful backup and recovery planning, USBs play a meaningul role in my strategy. So does Relax-and-Recover (ReaR), a modular and extensible (bash, and open source) Linux bare-metal disaster recovery solution that sits near the center of the most useful tools I deploy as "stock & standard". The main purpose of ReaR is to create bootable images from what is currently installed on a Linux host that can partition disks and retrieve a backup of the system. Options exist for where to save the bootable image and what to do with it after it has been created (the bootable image can be a USB device, an ISO file or a number of other options).

    This is easily one of the most useful tools in my entire kit, but let me first provide a little clarity as to ReaR's core functionality.  In using ReaR and recommending it to colleagues and clients, a misconception I often encounter is the expectation that ReaR is a backup tool - it can perform that function, but that is not a primary and is dependent upon your configuration.  ReaR focuses on Disaster Recovery, not backups, by instead providing tight integration with common backup softwares (including, but not limited to: internal backup methods like tar and rsync, in addition to a fantastic number of 3rd party backup solutions like CommVault Galaxy, Bareos, Bacula, Duplicity, EMC Networker (Legato), Symantec Netbackup, HP DataProtector and IBM's Tivoli Storage Manager (TSM)).  

    Just as important as its integration and interoperability, ReaR is fantastically easy to install and use immediately within your Disaster Recovery strategy.  In my opinion, ReaR provides such a wealth of applicational use across my portfolio of backup and restore tools/applicatons, coupled with its simplicity in ease-of-use, that it would be a shame for you not to use it in applying your own strategy.  Basically, ReaR is a centrifugal force in my Disaster Recovery strategy, allowing me to deploy a range of options to mitigate risk against permanent data loss and ability to quickly recover from hardware failures.


    As you might suspect, you can find more information in the man page (man rear), but since I fear most readers will not peruse (or follow the convenient, direct links I typically provide) I am literally going to enlist verbatim from the ReaR website here.  I think it's worth repeating, word for word, and belaboring the point as to what ReaR brings to the table. How's that for gonging you over the head to get you to use this tool?!  To follow is a healthy enlistment of features that show why I keep ReaR front and center within my overall disaster recovery tools, and you should too:

    Bare metal recovery on dissimilar hardware

    support for physical-to-virtual (P2V), virtual-to-physical (V2P)

    support for physical-to-physical (P2P) and virtual-to-virtual (V2V)

    various virtualization technologies supported (KVM, Xen, Vmware)

    Support for various integrated boot media types, including:




    OBDR/bootable tape


    Support for various transport methods, including:






    CIFS (SMB)

    Extensive disk layout implementation, including:

    HWRAID (HP SmartArray)






    LUKS (encrypted partitions and filesystems)

    Two phase disk layout recovery, allows for reconfiguration before recovery, e.g.

    migrations from e.g. SWRAID to HWRAID, or unencrypted to encrypted partitions

    HWRAID reconfigurations

    migration from partitions to LVM

    Various techniques to help troubleshooting:

    structured log files and guided menus

    log files are moved to recovery image, and to recovered system (available in every step for debugging)

    advanced debugging options to help trace scripts or develop new functionality

    Integration with monitoring (e.g., Nagios/Opsview)

    Integration with schedulers (e.g., let cron recreate and transfer your images upon disk layout changes)

    Various best practices to assist recovery

    integrates with local bootloader (in case it is still possible, you can restore from local disk through Grub)

    automatic network and ssh configuration (for remote recovery)

    automatic serial console support (useful for recovery through iLO or KVM serial console)

    shell history-stuffing (stuff shell history with useful commands at every step)

    automatic recovery when possible, guided recovery when needed

    There.  Are these enough reason to be keeping ReaR front and center in your arsenal for Disaster Recovery? Yes, yes they are.

    The Dreaded Disaster Recovery Scenario

    Backup tools are great at backups.  Restoring? Not so much.  All to familiar is this type of dreaded discovery recovery scenario: a file system corruption has rendered a server or individual workstation caput.  Not to worry, because you take scheduled backups of your system.  But what's next for you here? A way is needed in getting that backup data back onto disk. Anyone that has been down this path knows and can relate (and, if you by chance haven't you will - everyone eventually gets their turn here!) - most backups from traditional backup applications and mechanisms simply do not restore full systems, but instead rebuild them if something goes horribly wrong with the operating system. While there is some value in this approach, it unfortunately and unrealistically relies on you knowing what the state of the system was. Par example:microblogs cloud linux baremetal disaster recovery usb proactive

      1. What configuration changes have been made since the installation?
      2. What additional software has been installed?
      3. What scripts have been put in place?

    That list could actually expand and go on for quite a bit.  While possible that you are such a diligent and highly proactive sysadmin you are able to manage all that, this is getting into that forbidden territory for me of spending way too much time with something when there exists a more secure and efficient way of going about it.  This is a problem that won’t solve itself; if you haven't manually maintained the details of all the customizations then wouldn’t it be really nice to be able to run a command to pull back the contents of all your local file systems as they were at the point of the last backup, allowing you to simply reboot and be back in business? Keeping ReaR front and center in your Disaster Recovery will do that for you!


    The wow-factor for me in use of ReaR really comes in exploring all the flexibility it affords within an overall Disaster Recovery strategy, complementing my chosen backup solutions and output media (e.g., fitting in perfectly with my favored use of Duplicity for backups and iPXE network booting with ISO images, or using CommVault, or using Bareos, or using tar and USBs or... the important piece here is the "or").  However, our singular focus here is on bootable USBs (a more explorative article on ReaR within network booting scenarios is absolutely worth it, and forthcoming).  If you create a bootable image on a USB device then wouldn't it be nice to create a backup of your system on the same device?  Yes, ReaR does that, too.  Here's how I've used ReaR to create both backup of my full system and bootable restore image all on the same media for Ubuntu and RHEL.



    ReaR depends upon syslinux, but I highly recommend the modernized extlinux boot loaders. Install via Software Center.

    microblogs cloud linux baremetal disaster recovery usb extlinux

    The current, time-of-this-writing package for ReaR is rear_1.16.1_all.deb. Download for your distribution and install using the Gdebi Package Installer (I typically prefer this for .deb installs over Software Center as, imho, Gdebi resolves dependencies much better). 

    microblogs cloud linux baremetal disaster recovery usb gdebi

    Firstly, we need to Format our USB using ReaR.  This will rename the USB to REAR-000. And yes, you acknowledge that this will destroy all data currently on the USB :)

    sudo /usr/sbin/rear format /dev/sdc1

    With a properly formatted USB, we are now ready to create a bootable restore with a backup of the current system, applications and settings/preferences all saved onto to the USB.

    Our parameters are setup using /etc/rear/local.conf; this file by default is empty of commands so I'm not going to back it up prior to edits. Using my handy SumoSudo custom launcher I open gEdit with elevated privileges and set params as:

    microblogs cloud linux baremetal disaster recovery usb localconf

     You can find here a list of scenarios and output parameters we could use for ReaR.

     To execute ReaR (with verbose output) to create a bootable USB restore from backup saved to our USB, based on the above params we set in local.conf:

    sudo /usr/sbin/rear -v mkbackup

    You can find here a list of scenarios and output parameters we could use for ReaR.


    What now? With your new ReaR USB we can boot the system from rescue media, restore the disk layout (create partitions, RAID configuration and LVM; create and configure file systems), restore the backup data, restore the boot loader, inspect and reboot!

      ALWAYS TEST the USB to make sure you can boot and recover!!!


    Let's do the same then for our Red Hat Enterprise Linux system(s).  Our trusty EPEL Repository provides us with safe accessibiltiy to the ReaR rpms, but as with Ubuntu we first need to ensure we are using the more modern extlinux:

    microblogs cloud linux baremetal disaster recovery usb extlinux-rhel

    From and through PackageKit, we then install ReaR (Relax-and-Recover):

    microblogs cloud linux baremetal disaster recovery usb rear-rhel


    Also just as we did within Ubuntu, let's now create a bootable backup of our RHEL system to USBFormat your USB as we did above as REAR-000, and set the correct params in local.conf.

     From Terminal, kick off a backup onto USB:

    microblogs cloud linux baremetal disaster recovery usb bash-rear

    Here's a sample of the ReaR Workflow output based on our input paramaters above:

     microblogs cloud linux baremetal disaster recovery usb rear-output

    Do I really need to repeat and reiterate to Test the USB to ensure you can boot and recover? Throw up a test VM and boot and recover to make sure this is working, before you have to use this for real and find out something is amiss!

    Relax-and-Recover (ReaR) Demo Video

     ♠ If you found the above useful, you might also find to be of interest:

    Relax-and-Recover (ReaR) Project Page

    SUSE Disaster Recovery with ReaR

    IT3 Consultants ReaR Project Support

    EXTLINUX Wiki Page


    There are tools I love and then there are tools I really, really love.  ReaR is one of the latter.  And what I love about ReaR is that it fits my Disaster Recovery strategy almost no matter what approach and combination I'm taking: from backup mechanism, to backup location, to starting the rescue image, ReaR not only fits into, but complements almost any Disaster Recovery plan and tools I use to execute it, and let's face it - any good DR plan is one that is constantly being assessed and evolving to best-fit your environment and requirements.  What is really needed here is a more in-depth breakout of what ReaR brings to a full DR implementation (to sate, here is a sample DR scenario); but for now, this is how to create a bootable USB with ReaR for bare metal disaster recovery.

    More ...
  • iPXE Booting for Diskless Desktop Dancing

    IPXE Booting for Diskless Desk...

    Booting Linux Over the Network


    Now, that sounded dirty, didn't it?! Keeping my hands clean from manually managing hardware is what we are about in this blog post, so let's get down and dirty with iPXE booting over the network for diskless workstations. As most of you are likely tired of hearing, I really detest hardware overhead;

    I much prefer doing actual work for clients instead of wrangling with internal system maintenance, dealing with hardware and repetitively doing the same for the software needed for each instance.  None of that is making me any money; instead, it's sifting it out of me one desktop at a time.

    All that being said, and coming down off the old soapbox, I do of course have some physical equipment localized and vital to day-to-day business operations, performing test evaluations for clients, etc. Within my testing and analytics hackspace, my machines are purely purpose-built, in-house.  For desktops only needing general applicational use, I've been employing iPXE to boot over the network for diskless workstations.

    Don't Disk Me (Because I'm Diskless)

    Ironically, I do admit to drooling over the latest cloud-enhancing chipsets with multiplying cores, slick and sleek motherboards, gpu cards that rival NSA computational power (just kidding) and often obsess over local drive microblogs cloud ipxe-boot diskless-desktop applicationsstorage speeds, specifications and swap space.  Hardware stuff.  It's fun.  And, well, there's admittedly some pretty cool stuff happening across hardware these days in compute, networking and storage.  But, it certainly didn't take long in dealing with my small network of machines before coming to what should have already been an obvious and foregone conclusion: if the primary applications needed for these desktops are basically web browsers and e-mail clients mixed in with some other tools inherent in Linux, if I didn't need to use any other proprietary or commercial applications (of course, and always, deploying Linux and open-source platforms) let alone having better things to do with my business day than manage machines?  Then there was really no need for full blown desktop deployments. The functional application and use-case for these machines is ideal for diskless workstations.

    Booting Over the Network

    It isn't hard to imagine dealing with desktops over a large, ever-scaling network of clients, since we have all lived it, every day and for years, and some continue to do so.  Nope, not me; given my reluctance for burdensome hardware to begin with? I don't even want to think about it... booting over the network is microblogs cloud ipxe-boot diskless-desktop blkbootjust the dance card I was looking for - nothing new here, but the environment that makes this accomplishable is the Preboot eXecution Environment (PXE)PXE is an environment for booting a computer using a network interface independently of any local data storage devices. In simplistic terms, when PXE is used a computer will look for a configuration to boot from a remote server rather than a local hard disk (a DHCP server points to a TFTP server and specified a pxelinux.0 file to load from where we can opt to install various distributions).  You can do this with as few as 2 computers (1 server, 1 client) or with as many as you can get your hands on.  The client PXE code is directly included within the NIC's own firmware and also as part of the UEFI firmware on UEFI hardware.

    Pay specific distro attention and note to PXE Booting under EFI/UEFI: Ubuntu UEFI PXE netboot/install procedure and RHEL Configuring PXE Boot for EFI.

    While PXE is a well-known and relative standard here, interesting variants have emerged with enhanced feature sets.  As our working title indicates, I've been leveraging the open source derivative project iPXE and its highly expanded features, but we'll get to talking iPXE specifically in a few as it does build itself off standard PXE. 

    At the end of the day, I'm resulted with the ability to deploy workstations without need of local drives, an OS or IT oversight coupled with security and compliance advantages.  Diskless Workstations are but one, albeit essential, piece to my consultancy, so how does that work and what are the benefits?

    In my environment, the entire operating system is loaded via a compressed disk image over a Gigabit LAN, authentication is done via SSH, and home directories are mounted via NFS (although I do have one or more at a given time over iSCSI). All applications are run locally and are very fast – it is nearly unnoticeable that the machine is running entirely over the network. Behind the scenes there are two powerful servers in a hot-standby configuration that serve these diskless clients.

    TCO + Headless IT Administration

    ¤ Cost of Ownership: The TCO of this solution is absurdly low. Generic cost advantages: cost of ssd/hdd, cost of sata, cost of ata, cost of operating system (if proprietary or under support licensing), all canceled out.  Even within a relatively small hackspace network of 11 computers (1 server, 10 clients) we could potentially save (10 X (cost of hard drive)) + (10 X (cost of operating system)).  Compare this to the cost of managing any other OS configuration and it just blows everything else away.  

    ¤ Headless IT: Outside of my upfront + upgrade and ongoing maintenance costs for hard/software, far more advantageous with PXE-based booting is that I can have all of my configurations stored on one machine. This means I spend less time running around to resolve software and hardware issues.  If you regularly install tens/hundreds/thousands of PC’s, you can start the installer on all those machines at once without needing to have individual boot/install media for each machine (heck, you can even use Linux PXE for starting Microsoft Windows network installers and tools). 

    If you've ever seen my analytics and testing lab and the machine builds done by my own hands, you know and realize I do love tinkering with hardware (the "cool stuff").  But doing so is a calculated measure towards highly purpose-built machines for very specific use-cases; hardware overheard only enters my fold to address an absolute and imperative necessity.  Otherwise, this type of IT admin function would be better relegated to more of a weekend, garage-based hobby - in the throws of driving meaningful business operations managing hardware/software really only means I'd be losing money; the "cool factor" is a "cost factor".  Even when necessitated towards securing physical hardware and software to exercise it, having this setup affords my consultancy a "headless IT" model and promotes tighter security around devices and data.


    Benefits of Diskless Workstations:

      • Secure: eliminates virus and malware threats
      • Compliant: no sensitive information is ever stored on local disks
      • Readily Accessible: all the great software needed to work and be entertained (mostly, Spotify!) is easily available
      • Reduced Downtime: hardware failures are a non-issue
      • Headless IT: support costs and IT support time is near zero
      • TCO: purchase/raw hardware costs for diskless machines is minimal (additionally, see "Headless IT", above)

    The negatives? Well, at times I've found ISO images slow to load over TFTP (an issue with TFTP, not my network or NIC cards/hardware, thank your very little).  Other than some things to work through in the initial setup, this is really about the only negative I have, a minimal one at best.  Enter (finally) iPXE, which allows for much faster booting / loading of ISO images; iPXE resolves this issue as it can work over HTTP / iSCSI and other protocols - even wireless!  For some, the initial iPXE setup may be a little daunting, but the rewards have been many on my end. 





    It's worth mentioning here a highly useful PXE deployment utility: ERPXE.  I've used this for network booting and to resolve a range of issues as one of my "stock & standard" server installs.  ERPXE is a complete PXE solution featuring a broad range of recovery tools and various OS installations in one box, with a primary goal to make the PXE experience less "painful" for IT admins everywhere. ERPXE can do quite a lot, actually (all from its network location), more than I'm capable of adequately trying to deal with here in a post that is already long in the tooth... errr, mouth.  I recommend taking the time to discover and apply ERPXE - quite handy and borrowing from CBS Golf commentary, "useful!"  Version 2.0 of ERPXE will be released soon as a tar.gz file and as a Virtual Machine Template.  The ERPXE project projects 2.0 will bring a big change to the way PXE is used!


    You will first need a DHCP server with PXE capabilities or using Dnsmasq to add PXE options to your current router. You can use DD-WRT or a Linux/Windows DHCP Server, they all support PXE.  If you want to use your Router DHCP and add PXE settings then you can ADD Dnsmasq to your network.  You can also use Dnsmasq as your primary DHCP server - turning off the Router DHCP service.  There is no difference in the PXE boot process between DHCPd and DNSMASQ.  Both will allow you to boot using pxelinux.0/gpxe/ipxe.


    ERPXE provides a handsome bevy of Plugins: Cloning and Deployment; Hardware Diagnostics; Operating System Installation; Linux Live; Recovery Tools; System Diagnostics; Windows PE.  That's Awesome Sauce!


    ERPXE Advanced Scripts - several small bash scripts are developed to help you maintain your ERPXE system. Nice!


      this blog post continues...


    PXE booting with the mentioned advantages should certainly give you happy feet, dancing around the data center.  It does me, but I've enhanced this model by employing the more rich open source project iPXE.  I prefer iPXE because of its ability to perform tasks beyond the scope of a legacy PXE ROM: tasks such as booting via HTTP or iSCSI, controlling the boot process with a script, DNS, FCoE, creating dynamic menus, etc. 

    microblogs cloud ipxe-boot diskless-desktop bootiPXE is developed by the persons who originally developed gPXE (which evolved from Etherboot), and is gPXE's official replacement.  iPXE is the leading open source network boot firmware licensed under the GNU GPL (with some portions under GPL-compatible licences) and is included in products from several network card manufacturers and OEMs.  It provides a full PXE implementation enhanced with additional features that allow booting from a web server via HTTP, from an iSCSI SAN, from a Fibre Channel SAN via FCoE, from an AoE SAN, from a wireless network, from a wide-area network, or from an Infiniband network.  Much to like!

    NOTE: iPXE supports the EFI and UEFI environments, as well as the standard PC BIOS but do your diligence here - although developing with priority, I'm not entirely confident UEFI support can be taken as stable.      

    Unlike a traditional PXE ROM, iPXE is able to boot over a wide area network such as the Internet and can be used on any platform that can boot an ISO image. This includes many cloud providers and physical hardware.  Its approach is procedural with scripts, which gives you a benefit that you can react better to errors and make more runtime choices.  You can use iPXE to replace the existing PXE ROM on your network card, or you can chainload into iPXE to obtain the features of iPXE without the hassle of reflashing.

    iPXE - The Versatile Boot Loader


     Dirty Dancing: The Requisite Stuff

    Here's the basic requirements for iPXE Network Boots on Diskless Workstations

    Make sure you are running the latest pxelinuxmicroblogs cloud ipxe-boot diskless-desktop dancing

    Avoid issues by setting SELinux to Passive mode, and check your firewall settings configured properly to allow the required traffic and services communications

    Configuring Linux Server to PXE boot / configure your Linux network to support PXE images (or validating it already does)

    Hardware/client that supports PXE boot, with a minimum 2GB RAM

    Hash-verified ISO of your chosen distro

    A fast network; diskless booting is only useful if your network can transfer data quickly

     While iPXE can be flashed to network cards – this seemed overkill for my environment and I prefer leaving the NIC ROM untouched, as provided by the OEM. In my case it was easier and preferred to ‘chainload’ iPXE from the normal PXE (Network Boot) process.


     Do You Wanna Dance? Go Diskless!

    Whether you use the extra features of iPXE or stick with standard PXE, you will need to build a PXE server to boot from image over the network.  To get started building your PXE server, most Linux distros provide clear and concise directions (and don't forget ERPXE - easy!):


    PXE MultiDistro Install (this is old, but provides a starting point for Ubuntu MultiDistro PXE boot)



    A Few Vids For Your Reference:

      iPXE Installation of Ubuntu Server


    Boot Ubuntu (live) over iPXE and NFS


    ♠ If you found this information useful or of interest, you might also find worth exploring:

    NetworkBoot: A Place Where Beginners Can Learn the Fundamentals of Network Booting

    Examples of Complete Solutions Built Around iPXE

    Syslinux / PXELinux Wiki

    PXE Boot Server Wiki

    Diskless Workstations Homepage


    It's finally the Weekend, and in spite of still working that automatically puts me into a good mood.  I could just go with The Ramones "Do You Wanna Dance?" here and leave it at that, but -

     you knew it was coming... the obligatory "Dirty Dancing" film reference and insert...

    More ...
  • SumoSudo: Custom Launcher to Run Graphical Commands as Root

    SumoSudo: Custom Launcher to R...



    Sometimes it's handy to have a utility when you run GUI programs that require root privileges (e.g. the network configuration applet).  Linux-law is to "Know Thy Terminal" commands, but if I can deploy something else that keeps me from having to slow down to do so? I know, six-and-one-half-dozen of the other here (but seriously, typing into terminal is a waste of time = FACT).  But, should you have the need for this type of thing (or, just want one), here's the How-To on it by speaking out of both sides of my mouth for Ubuntu and RHEL.

    While sudo is our go-to for safer root priv executions, you should never use normal sudo to start graphical applications as Root. If you've ever done this, whether mistakenly or purposefully, you've learned the hard way why not to!  Instead, use gksudo, a frontend to sudo (that simply links to the gksu command). Gksudo's primary purpose is to run graphical commands that need root without the need to run an X terminal emulator and using su directly; this obviously prevents files in your home directory becoming owned by Root. I'm not going to service the pros and cons argument here for doing this in the first place, nor am i going to enjoin the banter for pkexec versus what is now the admittedly deprecated gksudo. My Ubuntu system (14.014 LTS) already has gksudo, so I'm going to use it for my purposes here; this is just as easy to accomplish in RHEL (6.5) - those options are further provided, below; ENJOY!

    SumoSudo Application Launcher in Ubuntu

    Our goal here is to make a custom application launcher that runs gksudo, allowing us to then execute GUI applications with root privileges.  That's some #sumosudo!  To create this launcher in Ubuntu with Unity desktop, we have to set this up manually. Grab yourself a licensed-to-use .png icon for your launcher (or simply make one of your own) - the launcher icon needs to be porportionate across x-y axis (128x128 seems to work nicely for me, named in my example "sumosudo.png").

    To get the icon image in a proper directory, we need to open Nautilus with elevated privileges (something our new custom launcher intends to help us do going forward):

    $ sudo nautilus

    browse to: >computer >user >share >icons and drag & drop/cut & paste your new icon there (or to any other logical permanent directory where you can easily drill down on it)

    Let's find the application we need (gksudo) for our new launcher - this should be found located under /usr/bin/ - just remember this location for now as we will need it later in creating our launcher...

    microblogs cloud custom application launcher gui-as-root gksudo

    Now create a working desktop file by opening gedit with elevated privileges and encode the below text into the new file:

    $ sudo gedit

    Encode the new file with the following lines:

      • [Desktop Entry]
      • Name=YourNewApplicationName [enter a name for your new application launcher; in this example mine is "SumoSudo"]
      • Comment=Utility for Running Applications as Root [enter a descriptive comment as to what the launcher is for/does]
      • Exec=/usr/bin/gksudo [enter the location from earlier where we found our gksudo application]
      • Icon=/usr/share/icons/sumosudo.png [enter the location and name of your icon for this application launcher; in this example mine is "sumosudo.png"]
      • Terminal=false [specifies whether the application should run in a terminal window or not; set to "false", as this is not a Terminal application]
      • Type=Application [specifies the type of the launcher file; this will be an "Application"]
      • Categories=Developer [the category you would like to designate the launcher for Unity filtering - categorize any way you prefer, multiple categories are acceptable - separate Categories by semi-colon for multiples]

    Save this file named as "yourapplicationname.desktop" (in my example, "sumosudo.desktop") and to directory: usr/share/applications.   Your saved .desktop file should look as follows:

    microblogs cloud custom application launcher gui-as-root desktopfile


    Test and make sure our new application launcher is there, is accessible and is functioning as expected: search for it, open it and in my case I add this to the Unity Launcher for easier access.  In order to add your launcher to the Unity Launcher on the left, you select and drag it onto the Launcher panel.  Here's my new SumoSudo launcher!

    microblogs cloud custom application launcher gui-as-root unitysearch

    Running the application now from the Unity Launcher by dbl-clicking our application icon results in:

    microblogs cloud custom application launcher gui-as-root customlauncher

    Now you can simply type the application you want to run under gksudo!

    Applications Launcher Under Root in RHEL

    The complimentary approach to what we've done above in Ubuntu is accomplishable in RHEL via BEESU, a graphical wrapper for su in Fedora-based distros.  Install via PackageKit and configure beesu to your own liking; it comes with some handy scripts for Nautilus and plugins for gEdit.

    microblogs cloud custom application launcher gui-as-root install


    ♠ If you found the above useful, you may also find the following to be of interest:

     RootSudo in Ubuntu

    Unity Launchers and Desktop Files

     How to Add a Launcher in Ubuntu

    BEESU Homepage


    More ...
  • Cool 4 Code: I Really Don't Tek No (Mouthful of Diamonds)

    Cool 4 Code: I Really Don't Te...


    Here's some techno for your teknow - playlists to keep you happy while coding and IT-building for a New World of Work.  Keep it Coding!



    Would You Like Additional Information Related To This Topic? Then You May Also Find Helpful:

    12 Songs Inspired by Technology

    More ...
  • yumyum yellowdog update selinux

    Yumyum yellowdog update selinu

    Upgrades and Updates to Red Hat® Enterprise Linux®


    Firstly, let's just agree that there is likely going to be some disagreement here. Lots of technology topics will "top-off" people over the craziest things... this doesn't qualify as one of the bigger ones I can think of,

    # yum update selinux


    Security-Enhanced Linux (SELinux) is a project (initially developed by the NSA, fwiw) to implement mandatory access control (MAC) under Linux, executed in the kernel. A security context, or security "label", is the mechanism used by SELinux to classify resources (e.g., processes and files) on a SELinux-enabled system. This context allows SELinux to enforce rules for how and by whom a given resource should be accessed.

    On occassion, we may have need (I will leave out desire) to directly manage these security contextsRed Hat Global Support Services recommends disabling SELinux permanently only if you are certain you will never want to run SELinux in the future.  Per the Red Hat KB "How Do I Turn SELinux Off In Red Hat Enterprise Linux?,  "files created with SELinux disabled will not have the information necessary to function when SELinux is enabled; changing this requires a "relabel" of the filesystems, which can be a very time consuming operation." 

    That's good enough reasoning for me; if you start with SELinux enabled (as is by default in RHEL6), do not toggle it on and off again unecessarily! Our raison d'être here, however, is that there may be occassion where SELinux issues need to be looked into, and potentially addressed.  This a rather broad and fairly elusive topic, so this attempt is mainly in providing you with some SELinux Management Tools to get you started

    NOTE: It is highly advisable that you conduct your own study in this area as much as possible prior to making any changes in SELinux. Please reference the provided industry articles at the end of this post for a more complete reference of SELinux!


     What if we attempt to install or execute a program and receive a SELinux Unsupported error that looks like this?  If you want this addressed, you will need to manage SELinux!

    microblogs-cloud-yumyum yellowdog selinux error

    Let's take a look at how to Modify and Manage SELinux in a Real World Example:

    Ye Olde Terminal

    While attempting to install linux antivirus software, I ran into a "SELinux not supported" error that kept me from executing the installer.  To complete, we first have to temporarily disable SELinuxHow to do that, and why? Initially, I went about dealing with this via command-line by temporarily changing SELinux mode to "Permissive".  I will get into why you will want to do that a little bit later; for now we just want to make the appropriate changes so that I can finish the antivirus install.

    Run the following command to check if SELinux is running (returns Enforcing, Permissive or Disabled):

    # getenforce

    You can then effectively disable into Permissive mode by running:

    # setenforce 0

     When you have completed whatever tasks necessitated putting SELinux into "Permissive" in the first place, be certain to re-enable:

    # setenforce 1

     ∞ this blog post continues...

      SELinux Management Tools

    From just the initial foray into understanding what SELinux actually is and how best to use and manage, it was clear I would be spending time with SELinux and its policies often enough to need to be efficient and effective in those dealings.  My personal preference with all of this is to employ some handy tools already found in our available repos: selinux-config and system-config-selinux; these are part of the policycoreutils-gui package providing GUI utilities for managing the SELinux environment.  Install all of these through PackageKit:

     microblogs-cloud-yumyum yellowdog selinux configgui

    This also gives us access to the SELinux Management and SELinux Policy Generation Tools:

    microblogs-cloud-yumyum yellowdog selinux gui-installed

     Now we can use our SELinux Management GUI to change SELinux mode to Permissive via System »Administration »SELinux Management:

    microblogs-cloud-yumyum yellowdog selinux permissive

    SELinux is now temporarily disabled, while still logging access errors.  While in Permissive mode, I can complete the install my antivirus application.  We also now have available our SELinux Policy Generation Tool via Applications »System Tools »SELinux Policy Generation Tool:

    microblogs-cloud-yumyum yellowdog selinux policygeneration-tool

    ∞ this blog post continues... 

    In my case, I needed to make SELinux changes to install software, but it wasn't without some trepidation.  Fiddling with SELinux settings requires some dedication and persistence in understanding what SELinux is and does, and how best to manage it.   Unless you are already experienced and knowlegeable here, my recommendation is to make use of the security ehnancements SELinux provides (by staying in the default of "Enforce"), and always utilize "Permissive" mode should you really need to disable it.  Review your access/error logs as habit.

    Permission to be Permissive

    Instead of disabling SELinux, it is more advisable to put SELinux in "Permissive" mode. In this mode:

    The SELinux policies will remain loaded,

    Access attempts that violate the configured SELinux policy will still be logged, but

    Access attempts that violate the configured SELinux policy will not be denied, thus disabling the protections offered by SELinux.


    Here's how to review your Access Logs to see what policies were logging while in Permissive -

    Search for auditd (the Linux Auditing System) and install if necessary - the audit RPM should be installed by default on most Red Hat Enterprise systems:

    microblogs-cloud-yumyum yellowdog selinux auditpkg


    Next, check for the setools-gui pkg, and install - this will provide a collection of graphical and command-line tools to efficiently address SELinux policy analysis:

    microblogs-cloud-yumyum yellowdog selinux setools

    Once installed, run your seaudit gui to access and review your logs (Applications »System Tools »SELinux Audit Log Analysis):

    microblogs-cloud-yumyum yellowdog selinux seaudit

     We also now have several other SELinux tools available for use - SELinux Policy Analysis (examine, search and relate policy components and rules) and SELinux Policy Difference (allows you to compare two policy files):


    microblogs-cloud-yumyum yellowdog selinux systemtools


     Lend Me Your Thoughts & Advice... How are You Handling SELinux in RHEL?

    My own approach and advice is to employ the default "Enforce" of SELinux and its policies, entering "Permissive" mode temporarily and only when entirely necessary, and habitually reviewing access logs for errors while doing so.  That being said, there certainly exists strong opinion that it takes more in managing SELinux than rewarded ultimately in security concerns.   I have yet to encounter any issues, and consider SELinux as a welcome, albeit additional, security layer versus online content and application bugs - my fear in looking into SELinux, is that if and when I do ever encounter any SELinux related issues? I could have more trouble than it's worth on my hands.  Let's hope I didn't just jinx myself... opinions differ on SELinux, some of it strongly:

    stopdisablinglinux - from "Seriously, stop disabling SELinux"

    SELinux Fails Again - excerpts from a frustrated SELinux user


    microblogs-cloud-yumyum yellowdog selinux yellowdogHaving generically delved into SELinux making minor adjustments, it was clear from colleagues and my own hands-on experience I really need to learn a lot more about it. Even for Desktop services, I would recommend employing SELinux as Red Hat provides, but haven't found any harm thus far in the occassional disabling in Permissive mode. Frankly, I really wouldn't want to have to tackle SELinux Policies/Policy Management but, should situations dicatate otherwise I feel pretty good I have the tools now to help drill down on resolving those changes fairly quickly. 

    There does seem to be differences in opinion about using SELinux and/or its inherent complexity.  Stay tuned; there's quite a bit more I need to understand here before being more comfortable with applying policy changes and mods within SELinux.  For now, in RHEL I am managing SELinux policies with the above SELinux Management and Policy Generation Tools, while expecting SELinux to be of greater value being Enforced and only occassionally Permissive, over ever being entirely Disabled#yumyumyellowdog

    Would You Like Additional Information Related To This Topic? Then You May Also Find Helpful:

    SYSCONFIG: the as-is testing enviro system configuration at the time of this article =

    HARDWARE: Alienware X51 [Memory: 16GB RAM; Processer: 4th Gen Intel® Core™ i7 4770 Quadcore 8MB Cache @ 4.00GHz; Graphics: NVIDIA® GeForce® GTX 760 Ti with 2GB GDDR5; SSD: Samsung 850 Pro 512GB; HDD: Western Digital Black 1TB]

    SOFTWARE: Operating System [RHEL Workstation 6.5-x86_64 (Santiago)]

    This information is not an advertisement on ConsultED's part but merely alerts Members to a potentially useful company, website, application or idea.
    More ...
  • yumyum yellowdog update eset

    Yumyum yellowdog update eset

    Upgrades and Updates to Red Hat® Enterprise Linux®


    Recently, I've been putting ESET Antivirus Business Edition for Linux Desktop on Ubuntu laptops.

    # yum update eset

    INSTALLING ESET ANTIVIRUS (Business Edition for Linux Desktop)

    Having previously installed a Free Trial Version of ESET Home Desktop for Linux on this Red Hat machine, I will need to perform an uninstall first.  You can obviously run Terminal here, but I'd like to see how ESET's Uninstaller handles itself.   

      From »Applications »System Tools locate and execute the "ESET NOD32 Antivirus Uninstaller".

     microblogs-cloud-yumyum yellowdog eset uninstallmenu

    As discussed in a prior post, the root password is required for ESET to Install/Uninstall: 

    microblogs-cloud-yumyum yellowdog eset runasroot

     Run through the uninstaller with your options (if any other than default) until done; a system restart will be needed now so get yourself rebooted:

    microblogs-cloud-yumyum yellowdog eset systemrestart

    For the ESET Antivirus Business Edition for Linux software we now want to install, you will first need a Username/Password from ESET to secure the download and rip an install:

    microblogs-cloud-sudo-apt-get-update eset-biz-desktop access

    Post obligatory sign up/info forms, ESET will send you a Username and Password via email with your license files/keys - I went ahead and purchased a minimum 5 user license, but you can certainly opt for the Free Business Trial instead.

    In the interest of time and clarity, all you really need to do here is follow the download and installation KB ESET has provided.  Installation is as easy as it gets, aside from a minor issue with SELinux, described separately below.

    With your newly received credentials and license files, simply download the ESETsoftware correctly to match your architecture and follow the installation guide; for me this will be 64-bit: http://download.eset.com/download/unix/eavbe/ueavbe.x86_64.en.linux

    NOTE: I was missing a library - yum install glibc.i686; keep an eye out for additional libraries that your system may require.


    Post-installation and restart you should be all set, with ESET!  

    microblogs-cloud-yumyum yellowdog eset installationscan



    SELinux is an enhanced security implementation that allows system admins to define how applications and users can access different resources such as files, devices, networks and inter-process communication. As with ESET, some installers and programs will require root access to execute; as you should have encountered, this will cause a conflict and an unsupported error ("SELinux not supported") when attempting to run the installer:

    microblogs-cloud-yumyum yellowdog eset selinux

    The ESET KB Installation Guide takes the position of disabling SELinux.  I'm still exploring the security advantages of SELinux and prefer to have this functionality "always on", so for the time being I utilize SELinux Management to temporarily allow for Permissive mode.

     Interestingly, take note on the Permissions tab of an option for "SELinux Context" while changing the installer's file permissions, as shown in the ESET KB installation instructions article.   "Not knowing, I hesitate to answer" is an applicable old saying here: not knowing what these values mean, or repurcussions for changing them, I left this item at its default "User data" setting.

     microblogs-cloud-yumyum yellowdog eset properties

     REFERENCE: For ways to manage SELinux in RHEL, please see "yumyum yellowdog update selinux"



    microblogs-cloud-yumyum yellowdog eset yellowdogThe ESET Remote Administrator (ERA) is but one of the reasons I chose ESET for linux antivirus protection; a singular console to remotely install and administer antivirus software across my entire network was highly appealing over other open source and proprietary linux antivirus offerings I looked into.  No network, and all of the devices the comprise it, is completely immune to digital threats; appropriately protecting your linux devices, systems and networks is essential.  This post serves for your reference as one method for installing ESET NOD32 Antivirus Business Edition for Linux Desktop, in RHEL. I will absolutely post back similar once I've installed the ESET Remote Administrator#yumyumyellowdog

    Would You Like Additional Information Related To This Topic? Then You May Also Find Helpful:

    SYSCONFIG: the as-is testing enviro system configuration at the time of this article =

    HARDWARE: Alienware M11x [Memory: 8GB RAM; Processer: Intel® Core™ i7 Quadcore CPU U640 @ 1.200GHz × 4; SSD: Samsung 840 Pro 250GB]

    SOFTWARE: Operating System [RHEL Desktop 6.5-x86_64 (Santiago)]

     This information is not an advertisement on ConsultED's part but merely alerts Members to a potentially useful company, website, application or idea.
    More ...
  • sudo apt-get update eset business desktop antivirus for linux

    Sudo apt-get update eset busin...

     Upgrades and Updates in Ubuntu


    After recently installing ESET Antivirus for Linux in the home desktop flavor, I wanted to make use of ESET's Remote Administrator available in their Linux Business Desktop edition to better manage network security from a single location.  Cross-platform security with unified management sounds really good to me.  Delving into the ERA (ESET Remote Administrator) is going to call for its own separate blog post(s), however; here we are just doing a straight install of the Linux Business Desktop Edition of the antivirus onto one machine.  A rather old Alienware m9750 running 64bit Ubuntu 14.04 Desktop is what we're working with to try this out, so here goes some #sumosudo


    sudo apt-get update eset


    To upgrade to the Business Desktop Edition, we will first need to uninstall the pre-existing ESET Home Desktop.  If you are coming into this without an existing ESET installation, just take this jumper to the "section" for a fresh install. 

     Locate ESET via the Unity Dash, and execute the "ESET NOD32 Antivirus Uninstaller".


    As discussed in a prior post, the root password is required for ESET to Install/Uninstall, something we don't normally want to do in Ubuntu - I purposefully left my root password enabled from before so nothing to do here but enter it.  

    microblogs-cloud-sudo-apt-get-update eset-biz-desktop root

    Please reference "sudo apt-get update eset home desktop" if you are needing to set a root password.


    Run through the uninstaller with your options (if any other than default) until done; a system restart will be needed now so get yourself rebooted.

    microblogs-cloud-sudo-apt-get-update eset-biz-desktop restart

    For the ESET Antivirus Business Edition for Linux software we want to upgrade to, you are first going to need a Username/Password from ESET to secure the download and rip an install.

    microblogs-cloud-sudo-apt-get-update eset-biz-desktop access

    Post obligatory sign up/info forms, ESET will send you a Username and Password via email with your license files/keys - I went ahead and purchased a minimum 5 user license, but you can certainly opt for the Free Business Trial instead.

    From here, this is essentially a repeat of the steps from my prior blog post, "sudo apt-get update eset home desktop". 

    In the interest of time and clarity, all you really need to do here is follow the download and installation KB ESET has provided.  With your newly received credentials and license files, download the ESET software correctly to match your architecture and follow the installation guide; for me this will be 64-bit: http://download.eset.com/download/unix/eavbe/ueavbe.x86_64.en.linux  

     Interestingly, I note on the Permissions tab an option for "SELinux Context", as shown in the above kb article.  SELinux isn't an issue for Ubuntu-based installs; Debian packaged Linux kernels have SELinux support compiled in, but disabled by default.  This did not appear during my Properties change as I'm in Debian/Ubuntu here; if you are interested in this item please reference "yumyum yellowdog update selinux" for enhanced details of SELinux.  

    Post-installation and restart you should be all set, with ESET!  

    microblogs-cloud-sudo-apt-get-update eset-biz-desktop installed

     Optional, but I typically like to ensure newly installed applications that weren't handled through Software Center are showing correctly from within the Dash.  From the Unity interface quick launch bar, Search the Dash Applications for ESET just to make sure it is there:

    microblogs-cloud-sudo-apt-get-update eset screencap04

    ESETAntivirus Business Edition for Linux Desktop prevents malware through detection of multi-platform threats, regardless of what system is being targeted - Windows®, Linux or Mac® OS. Now that's some #sumosudo! Lend me your thoughts on this approach, as well as functional alternatives.


    microblogs-cloud-sudo-apt-get-update eset-biz-desktop robotAccording to ESET, both the Home Desktop and Business Desktop for Linux distros are exactly the same antivirus offering.  The differentiator is in the ESET Remote Administrator that you get with the Business Edition for Desktop Linux.  The ERA is one of the reasons I chose ESET for linux antivirus protection; a singular console to remotely install and administer antivirus software across my entire network was highly appealing over other open source and proprietary linux antivirus offerings I looked into.  No network, and all of the devices the comprise it, is completely immune to digital threats; appropriately protecting your linux devices, systems and networks is essential.  This post serves for your reference as one method for installing ESET NOD32 Antivirus Business Edition for Linux Desktop, in Ubuntu. I will absolutely post back similar once I've installed the ESET Remote Administrator#sumosudo

    Would You Like Additional Information Related To This Topic? Then You May Also Find Helpful:

    SYSCONFIG: the as-is testing enviro system configuration at the time of this article =

    HARDWARE: Alienware Area-51 M9750 [Memory: 4GB RAM; Processer: Intel® Core™2 CPU T7200 @ 2.00GHz × 2; Graphics: Gallium 0.4 on NV49; SSD: Samsung 840 Evo 120GB; HDD: Western Digital Blue 500GB]

    SOFTWARE: Operating System [Ubuntu Desktop 14.04 LTS 64-bit]; Antivirus [ESET NOD32 Business Desktop Antivirus]

    This information is not an advertisement on ConsultED's part but merely alerts Members to a potentially useful company, website, application or idea.
    More ...


  • JFile: :read: Unable to open file: http://www.consult-ed.org/templates/jbpowerplay/css/theme.css
  • JFile: :read: Unable to open file: http://www.consult-ed.org/templates/jbpowerplay/css/hiliteRed.css
  • JFile: :read: Unable to open file: http://www.consult-ed.org/templates/jbpowerplay/css/bgBlackPattern.css
  • JFile: :read: Unable to open file: http://www.consult-ed.org/templates/jbpowerplay/css/mainBrown.css
  • JFile: :read: Unable to open file: http://www.consult-ed.org/templates/jbpowerplay/css/bottomBlue.css
More Info


Social SignOn

SignIn Here

ED bubble transparent2WE ARE INFORMATION EMPOWERED. Providing innovative solutions to innovative business, ConsultED delivers a power play of game changing open source, cloud-based technology strategies and solutions to empower organizations with global competitive advantage. Our Mission is Your Success: Business Intelligence, Cloud Computing, Mobile Systems, Open Source, OpenStack, Security & Compliance, Social Networks & Media, Sustainability, Web Services, and Electronic Discovery Consulting.