Tag: linux

Kali on ChromeBook

http://www.kali.org/wp-content/uploads/2013/03/k-blog.pngI recently purchased a Samsung ChromeBook. Not for ChromeOS, but for the fact that Kali Linux – the network pen-test successor to BackTrack – announced a ChromeBook build. I figured I couldn’t go wrong with $250 for a Linux wireless ultra-portable dedicated to network testing. Turns out perhaps I could go wrong. (continue reading…)

Share/Bookmark

Keeping Track of iSCSI LUNs as Multipath Devices

The Dell MD3200i is a very flexible mid-level iSCSI SAN. With 12 bays (up to 3TB NearLine SAS in each) and dual quad-port controllers, it offers excellent redundancy, capacity, and expandability. The Windows or Linux MD Storage Manager provides a decent GUI from which to define disk groups of various RAID styles and virtual volumes within each disk group for future filesystems.

But for all the labeling controls that MDSM offers for groups and volumes, the LUN mappings (to allocate volumes to iSCSI IP connections) are the real exposed labels. No matter how anal-retentive you get with group/volume hierarchy, all the ‘naming’ that the iSCSI initiators will ever see are the LUN numbers 0-31.

In an iSCSI system, there could be multiple ways to reach LUNs (via multiple network interfaces). For this reason, multipath support is used to provide route management and redundancy. On CentOS, filesystems are accessed via the multipath /dev/mapper device naming, mapped to the ‘physical’ iSCSI LUN. How are these mappings managed? ‘mpatha‘, ‘mpathb‘, ‘mpathc‘, etc are assigned first-come first-served to LUNs in the order they are discovered. This can make it difficult when adding multiple LUNs at the same time, because it is not entirely obvious which /dev/mapper/mpath device corresponds to which partition (despite all that effort you employed in creatively naming your MD3200i groups and volumes).

Because of my momentary confusion in regard to this LUN mapping, I thought that I would document the iSCSI implementation steps as performed on CentOS 6:

(continue reading…)


sudo Authentication via SSH Agent

On Linux hosts (CentOS6), I’ve taken great care to utilize two-factor remote shell authentication and limit root access with sudo. But while SSH authentication via the Pageant agent works great for Putty on Windows, with no /etc/passwd password required, it always struck me funny that a password was still needed for sudo authentication.

If only there was a way to use the SSH key-pair to authenticate the sudo access and not require the /etc/passwd password prompt at all. There is!

(continue reading…)


  • DarkSideGeek on Twitter

  • New This Month

    September 2017
    M T W T F S S
    « Apr    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Copyright © 1996-2010 The Dark Side Geek. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress
    %d bloggers like this: