Administration
  Home arrow Administration arrow Page 5 - Advanced Concepts on Dealing with File...
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Advanced Concepts on Dealing with Files and Filesystems in BSD
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 7
    2007-01-04

    Table of Contents:
  • Advanced Concepts on Dealing with Files and Filesystems in BSD
  • HACK#19: Access Windows Shares Without a Server
  • HACK#20: Deal with Disk Hogs
  • HACK#21: Manage Temporary Files and Swap Space
  • HACK#22: Recreate a Directory Structure Using mtree
  • HACK#23: Ghosting Systems

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    TestComplete™ automates software testing for a fraction of what the big guys charge. Easy functional and load testing for all Windows, .NET, Java and Web apps. Download a free trial now.

    Advanced Concepts on Dealing with Files and Filesystems in BSD - HACK#22: Recreate a Directory Structure Using mtree
    (Page 5 of 6 )

    Prevent or recover from rm disasters.

    Someday the unthinkable may happen. You're doing some routine maintenance and are distracted by a phone call or perhaps another employee's question. A moment later, you're faced with the awful realization that your fingers typed either arm *or arm -Rin the wrong place, and now a portion of your system has evaporated into nothingness.

    Painful thought, isn't it? Let's pause for a moment to catch our breath and examine a few ways to prevent such a scenario from happening in the first place.

    Close your eyes and think back to when you were a fresh-faced newbie and were introduced to the omnipotentrmcommand. Return to the time when you actually readman rmand first discovered the-iswitch. "What a great idea," you thought, "to be prompted for confirmation before irretrievably deleting a file from disk." However, you soon discovered that this switch can be a royal PITA. Face it, it's irritating to deal with the constant question of whether you're sure you want to remove a file when you just issued the command to remove that file.

    Necessary Interaction

    Fortunately, there is a way to request confirmation only when youre about to do something as rash asrm *. Simply make a file called -i. Well, actually, it's not quite that simple. Your shell will complain if you try this:

      % touch -i
      touch: illegal option -- i
      usage: touch [-acfhm] [-r file] [-t [[CC]Y]MMDDhhmm[.SS]] file ...

    You see, to your shell, -i looks like the-iswitch, whichtouchdoesn't have. That's actually part of the magic. The reason why we want to make a file called -i in the first place is to fool your shell: when you typerm *, the shell will expand*into all of the files in the directory. One of those files will be named -i, and, voila, you've just given the interactive switch torm.

    So, how do we get past the shell to make this file? Use this command instead:

      % touch ./-i

    The./acts as a sort of separator instruction to the shell. To the left of the./go any options to the commandtouch; in this case, there are none. To the right of the./is the name of the file totouchin "this directory."

    In order for this to be effective, you need to create a file called -i in every directory that you would like to protect from an inadvertentrm *.

    An alternative method is to take advantage of thermstarshell variable found in thetcshshell. This method will always prompt for confirmation of arm *, regardless of your current directory, as long as you always usetcsh. Since the default shell for the superuser istcsh, add this line to /root/.cshrc:

      set rmstar

    This is also a good line to add to /usr/share/skel/dot.cshrc [Hack #9].

    If you want to take advantage of the protection immediately, force the shell to reread its configuration file:

      # source /root/.cshrc

    Using mtree

    Now you know how to protect yourself fromrm *. Unfortunately, neither method will save you from arm -R. If you do manage to blow away a portion of your directory structure, how do you fix the mess with a minimum of fuss, fanfare, and years of teasing from your coworkers? Sure, you can always restore from backup, but that means filling in a form in triplicate, carrying it with you as you walk to the other side of the building where backups are stored, and sheepishly handing it over to the clerk in charge of tape storage.

    Fortunately for a hacker, there is always more than one way to skin a cat, or in this case, to save your skin. That directory structure had to be created in the first place, which means it can be recreated.

    When you installed FreeBSD, it created a directory structure for you. The utility responsible for this feat is calledmtree.

    To see which directory structures were created withmtree:

      % ls /etc/mtree/ 
     

    ./

    BSD.root.dist

    BSD.x11-4.dist

    ../

    BSD.sendmail.dist

    BSD.x11.dist

    BSD.include.dist

    BSD.usr.dist

     

    BSD.local.dist

    BSD.var.dist

     

    Each of these files is in ASCII text, meaning you can read, and more interestingly, edit their contents. If you're a hacker, I know what you're thinking. Yes, you can edit a file to remove the directories you don't want and to add other directories that you do.

    Let's start with a simpler example. Say you've managed to blow away /var. To recreate it:

      # mtree -deU -f /etc/mtree/BSD.var.dist -p /var

    where:

    -d

    Ignores everything except directory files.

    -e

    Doesn't complain if there are extra files.

    -U

    Recreates the original ownerships and permissions.

    -f /etc/mtree/BSD.var.dist

    Specifies how to create the directory structure; this is an ASCII text file if you want to read up ahead of time on what exactly is going to happen.

    -p /var

    Specifies where to create the directory structure; if you don't specify, it will be placed in the current directory.

    When you run this command, the recreated files will be echoed to standard output so you can watch as they are created for you. A few seconds later, you can:

      % ls /var

    ./

    crash/

    heimdal/

    preserve/

    yp/

    ../

    cron/

    lib/

    run

     

    account/

    db/

    log/

    rwho/

     

    at/

    empty/

    mail/

    spool/

     

    backups/

    games/

    msgs/

     

     

    That looks a lot better, but don't breathe that sigh of relief quite yet. You still have to recreate all of your log files. Yes, /var/log is still glaringly empty. Remember,mtreecreates a directory structure, not all of the files within that directory structure. If you have a directory structure containing thousands of files, you're better off grabbing your backup tape.

    There is hope for /var/log, though. Rather than racking your brain for the names of all of the missing log files, do this instead:

      % more /etc/newsyslog.conf
     
    # configuration file for newsyslog
      # $FreeBSD: src/etc/newsyslog.conf,v 1.42 2002/09/21 12:07:35 markm Exp $
      #
      # Note: some sites will want to select more restrictive protections than the
      # defaults. In particular, it may be desirable to switch many of the 644
      # entries to 640 or 600. For example, some sites will consider the
      # contents of maillog, messages, and lpd-errs to be confidential. In the
      # future, these defaults may change to more conservative ones.
      #

    # logfilename

    [owner:group]

    mode

    count

    size

    when

    [ZJB]

    [/pid_file] [sig_num]

     

     

     

     

     

     

    /var/log/cron

     

    600

    3

    100

    *

    J

    /var/log/amd.log

     

    644

    7

    100

    *

    J

    /var/log/auth.log

     

    600

    7

    100

    *

    J

    /var/log/kerberos.log

     

    600

    7

    100

    *

    J

    /var/log/lpd-errs

     

    644

    7

    100

    *

    J

    /var/log/xferlog

     

    600

    7

    100

    *

    J

    /var/log/maillog

     

    640

    7

    *

    @T00

    J

    /var/log/sendmail.st

     

    640

    10

    *

    168

    B

    /var/log/messages

     

    644

    5

    100

    *

    J

    /var/log/all.log

     

    600

    7

    *

    @T00

    J

    /var/log/slip.log

    root:network

    640

    3

    100

    *

    J

    /var/log/ppp.log

    root:network

    640

    3

    100

    *

    J

    /var/log/security

     

    600

    10

    100

    *

    J

    /var/log/wtmp

     

    644

    3

    *

    @01T05

    B

    /var/log/daily.log

     

    640

    7

    *

    @T00

    J

    /var/log/weekly.log

     

    640

    5

    1

    $W6D0

    J

    /var/log/monthly.log

     

    640

    12

    *

    $M1D0

    J

    /var/log/console.log

     

    600

    5

    100

    *

    J

    There you go, all of the default log names and their permissions. Simplytouchthe required files and adjust their permissions accordingly withchmod.

    Customizing mtree

    Let's get a little fancier and hack themtreehack. If you want to be able to create a homegrown directory structure, start by perusing the instructions in /usr/src/etc/mtree/README.

    The one rule to keep in mind is don't use tabs. Instead, use four spaces for indentation. Here is a simple example:

      % more MY.test.dist
     
    #home grown test directory structure
      /set type=dir uname=test gname=test mode=0755
      .
        
    test1
         ..
          
    test2
               subdir2a
               ..
               subdir2b
                 
    ..
                  subsubdir2c mode=01777
                  ..
                  ..
        
    ..

    Note that you can specify different permissions on different parts of the directory structure.

    Next, I'll apply this file to my current directory:

      # mtree -deU -f MY.test.dist

    and check out the results:

      # ls -F
      test1/
      test2/
      # ls -F test1
      #
      # ls -F test2
      subdir2a/
      subdir2b/
      # ls -F test2/subdir2b
      subsubdir2c/

    As you can see,mtreecan be a real timesaver if you need to create custom directory structures when you do installations. Simply take a few moments to create a file containing the directory structure and its permissions. You'll gain the added bonus of having a record of the required directory structure.

    See Also

    • man mtree
    • The Linuxmtree port (http://www.wie-auch-immer.de/mtree/)

    More Administration Articles
    More By O'Reilly Media


       · This article is an excerpt from the book "BSD Hacks," published by O'Reilly. We hope...
     

    Buy this book now. This article is excerpted from chapter two of the book BSD Hacks, written by Dru Lavigne (O'Reilly, 2005; ISBN: 0596006799). Check it out today at your favorite bookstore. Buy this book now.

       

    ADMINISTRATION ARTICLES

    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...
    - Dealing with Files and Filesystems
    - More Hacks for the User Environment in BSD
    - Personalizing the User Environment in BSD
    - Customizing the User Environment in BSD

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway