Wednesday, October 10, 2012

Installing NFS Services on Ubuntu 12.10

The services required to enable NFS folder sharing are not installed by default on Ubuntu. They can easily be installed, however, by opening a terminal window and entering the following command:

#sudo apt-get install nfs-kernel-server

The installation process should automatically start the NFS service. To verify that the service is indeed running, execute the following command:

#sudo /etc/init.d/nfs-kernel-server status

If the output from the above command indicates that the service is not running, it may started as follows:

#sudo /etc/init.d/nfs-kernel-server start

Sharing Folders


Configuring an NFS server is as simple as placing a line in the /etc/exports file. That line has three pieces of information:

    The directory to be shared (exported)
    The computer, NIS group, hostname, domain name or subnet allowed to access that directory
    Any options, such as ro or rw, or several other options

Any folders which are to be shared are listed in the /etc/exports file which may be edited from a terminal window as follows. There's one line for each directory being shared. The general syntax is:

directory_being_shared subnet_allowed_to_access(options)

#sudo gedit /etc/exports

Each folder that is to be shared via NFS must have an entry in this file. The basic syntax is as follows:

(permissions)

For example, to allow a system with the IP address of 192.168.2.24 to access /tmp with read-only access, the following entry would be added to the /etc/exports file:

/tmp    192.168.2.24(rw,sync,no_subtree_check)

Similarly, to also make the folder accessible to a system with the hostname ubuntu2 with read/write permission, the line would read as follows:

/tmp    192.168.2.24(ro,sync,no_subtree_check) ubuntu2(rw,sync,no_sub_tree_check)

Alternatively, to provided read/write access to all hosts, simply use the wildcard character (*):

/tmp    *((rw,sync,no_sub_tree_check)

Once the folder entries have been made in the /etc/exports file, the current settings may be checked at any time by running the exportfs command:

#sudo exportfs
/tmp              192.168.2.24

Mounting an NFS Share on a Client

Mounting an NFS share on a client can be simple. At its simplest it might look like this:

#mount -t nfs -o ro 192.168.100.85:/data/altamonte /mnt/test

That same mount can be performed in /etc/fstab with the following syntax:

#192.168.100.85:/data/altamonte   /mnt/test   nfs   rw   0   0

There are many mount options that can be used, and those are listed in this article.

Tuesday, October 9, 2012

Ubuntu 12.10 - Wifi Network was not Deteceted

I was experiencing a problem in configuring a Toshiba laptop for wireless access. It did not identified avaialable wireless networks.

First to check the available PCI devices, I used the below command "lspci". lspci is a utility for displaying information about PCI buses in the system and devices connected to them. By  default,  it  shows  a  brief list of devices.

#lspci

Output for the above command:

....
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8723
03:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v2.0 Fast Ethernet (rev c1)
....

I found a solution suggested on the web http://askubuntu.com/questions/139632/wireless-card-realtek-rtl8723ae-bt-is-not-recognized

In the above list, I found that the available wifi card is from Realtek. Realtek is making the official Linux driver available unofficially (via Dropbox). For unknown reasons, neither the Windows nor Linux drivers are available on their website (yet). But Realtek tech support has been providing a Dropbox link with the source code/firmware tarball which numerous users have reported as working.

Where do I get it? Is it safe? The driver can be downloaded via this Dropbox link. The downloaded file has the following MD5 or SHA1 hashes: (which you can verify with md5sum or sha1sum).

    MD5: fd10e9a347c6447f649324d6bdab53de
    SHA1: 1ccd6ae73878d8bf65bd7c0384e333b121606230

To install the above driver, I followed the below steps.

Open a terminal with Ctrl+Alt+T.
Since I haven't installed "build-essential", I had to first install them using the below command.

#sudo apt-get install build-essential linux-headers-generic linux-headers-`uname -r`

Pasted the below line to download and extract the driver archive in one single step:

#wget -O- http://dl.dropbox.com/u/57056576/DRIVERS/REALTEK/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012.tar.gz | tar -xz

Note: You can directly download this from the website using http://dl.dropbox.com/u/57056576/DRIVERS/REALTEK /rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012.tar.gz. Then you need to extract it to a folder.

Then I changed to the extracted driver's directory.

#cd rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012

To instal the driver, I used the below command.

#make

But I was getting the below error.

make -C /lib/modules/3.4.6-2.10-default/build M=/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012 modules
make[1]: Entering directory `/usr/src/linux-3.4.6-2.10-obj/i386/default'
CC [M] /home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012/base.o
/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012/base.c: In function ‘_rtl_init_mac80211’:
/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012/base.c:320:6: error: ‘IEEE80211_HW_BEACON_FILTER’ undeclared (first use in this function)
/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012/base.c:320:6: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012/base.o] Error 1
make[3]: *** [_module_/home/leraly/rtl_92ce_92se_92de_8723ae_linux_mac80211_0006.0514.2012] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-3.4.6-2.10-obj/i386/default'
make: *** [all] Error 2

To resolve the above error I followed the below steps. [Sorry I couldn't find some other way to solve the above error. Then I tried the below method]

Open the "base.c" file using my favourite text editor. Then I commented the line that contains "IEEE80211_HW_BEACON_FILTER". Then I saved the file and exit.

Again I followed the below steps.

#make
#sudo make install.

I was able to successfully installed the above driver.

To test the driver by loading it (this is a one-time step; after you reboot once, the driver should automatically load on every boot) I entered the below command:

#sudo modprobe rtl8723e

After rebooting the laptop, it was able to identified available wireless networks.

I can't gurantee that the above method will solve your problems but it worked for me... :)

Usefull SVN Commands

$svn help 

Provides a summary of the available commands. Available subcommands:
 
   add
   blame (praise, annotate, ann)
   cat
   changelist (cl)
   checkout (co)
   cleanup
   commit (ci)
   copy (cp)
   delete (del, remove, rm)
   diff (di)
   export
   help (?, h)
   import
   info
   list (ls)
   lock
   log
   merge
   mergeinfo
   mkdir
   move (mv, rename, ren)
   propdel (pdel, pd)
   propedit (pedit, pe)
   propget (pget, pg)
   proplist (plist, pl)
   propset (pset, ps)
   resolve
   resolved
   revert
   status (stat, st)
   switch (sw)
   unlock
   update (up)


#svn checkout or #svn co


This command is used to pull an SVN tree such as svn://linuxfromscratch.org/BLFS/trunk/BOOK (the BLFS Development book) from the server. You should only need to do this once. If the directory structure is changed (as is sometimes necessary), you may occasionally need to delete your local sand box and re-check it out.

#svn checkout URL[@REV]... [PATH]

Examples:
Check out a working copy into a directory called myrepo:

$ svn checkout svn://linuxfromscratch.org/BLFS/trunk/BOOK myrepo
A    myrepo/archive
A    myrepo/archive/inetutils.xml
A    myrepo/archive/espgs.xml
A    myrepo/archive/libosinfo.xml
A    myrepo/archive/gimp-print.xml
...
...

$ ls
myrepo

Check out 2 different directories into two separate working copies, but place both into a directory called working-copies:

$ svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz working-copies

Check out 2 different directories into two separate working copies:

$ svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz

If you interrupt a checkout (or something else interrupts your checkout like loss of connectivity, etc.), you can restart it either by issuing the identical checkout command again, or by updating the incomplete working copy:


#svn add.


When you are creating a new file or directory, you need to tell the SVN server about it. This command does that. Note that the file won't appear in the repository until you do an #svn commit

#svn add PATH...
Available switches:
    --targets FILENAME
    --non-recursive (-N)
    --quiet (-q)
    --config-dir DIR
    --auto-props
    --no-auto-props
    --force

Continue the above example:

Go inside the working copy.
#cd myrepo

Create your file using your favourit text editor

#vi foo.c

To add a file to your working copy:

#svn add foo.c
A         foo.c

When adding a directory, the default behavior of svn add is to recurse:

First create the directory inside the wokring folder. Then enter the below command.

#svn add testdir
A         testdir
A         testdir/a
A         testdir/b
A         testdir/c
A         testdir/d

You can add a directory without adding its contents:

#svn add --non-recursive otherdir
A         otherdir

Normally, the command svn add * will skip over any directories that are already under version control. Sometimes, however, you may want to add every unversioned object in your working copy, including those hiding deeper down. Passing the --force option makes svn add recurse into versioned directories:

#svn add * --force
A         foo.c
A         somedir/bar.c
A         otherdir/docs/baz.doc


#svn propset


Set PROPNAME to PROPVAL on files, directories, or revisions. The first example creates a versioned, local property change in the working copy, and the second creates an unversioned, remote property change on a repository revision.


#svn propset PROPNAME [PROPVAL | -F VALFILE] PATH...
#svn propset PROPNAME --revprop -r REV [PROPVAL | -F VALFILE] [URL]

Available switches:
    --file (-F) FILE
    --quiet (-q)
    --revision (-r) REV
    --targets FILENAME
    --recursive (-R)
    --revprop
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --encoding ENC
    --force
    --config-dir DIR

Continue the above example:

On a UNIX system, if you want a file to have the executable permission set:

#svn propset svn:executable ON foo.c
property 'svn:executable' set on 'foo.c'

Perhaps you have an internal policy to set certain properties for the benefit of your coworkers:

#svn propset owner sharma foo.c
property 'owner' set on 'foo.c'

If you made a mistake in a log message for a particular revision and want to change it, use --revprop and set svn:log to the new log message:

#svn propset --revprop -r 25 svn:log "Journaled about trip to Sri Lanka."
property 'svn:log' set on repository revision '25'

Or, if you don't have a working copy, you can provide a URL.

#svn propset --revprop -r 26 svn:log "Document nap." http://svn.red-bean.com/repos
property 'svn:log' set on repository revision '25'

Lastly, you can tell propset to take its input from a file. You could even use this to set the contents of a property to something binary:

#svn propset owner-pic -F sharma.jpg foo.c
property 'owner-pic' set on 'foo.c'


#svn commit


Send changes from your working copy to the repository. If you do not supply a log message with your commit by using either the --file or --message switch, svn will launch your editor for you to compose a commit message.

svn commit will send found lock tokens and release locks on all PATHS committed (recursively) unless --no-unlock is passed.

svn commit [PATH...]

Available switches:
    --message (-m) TEXT
    --file (-F) FILE
    --quiet (-q)
    --no-unlock
    --non-recursive (-N)
    --targets FILENAME
    --force-log
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --encoding ENC
    --config-dir DIR

Commit a simple modification to a file with the commit message on the command line and an implicit target of your current directory (“.”):


Continue the above example:

#svn commit -m "added file foo.c and directory testdir to the repo"
Adding         foo.c
Adding         testdir
Transmitting file data .
Committed revision 2.

Commit a modification to the file foo.c (explicitly specified on the command line) with the commit message in a file named msg:

#svn commit -F msg foo.c
Sending        foo.c
Transmitting file data .
Committed revision 2.

If you want to use a file that's under version control for your commit message with --file, you need to pass the --force-log switch:

#svn commit --file file_under_vc.txt foo.c
svn: The log message file is under version control
svn: Log message file is a versioned file; use '--force-log' to override

#svn commit --force-log --file file_under_vc.txt foo.c
Sending        foo.c
Transmitting file data .
Committed revision 4.

#svn delete


Items specified by PATH are scheduled for deletion upon the next commit. Files (and directories that have not been committed) are immediately removed from the working copy. The command will not remove any unversioned or modified items; use the --force switch to override this behavior.

Items specified by URL are deleted from the repository via an immediate commit. Multiple URLs are committed atomically.

#svn delete PATH...

Available Switches
    --force
    --force-log
    --message (-m) TEXT
    --file (-F) FILE
    --quiet (-q)
    --targets FILENAME
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --editor-cmd EDITOR
    --encoding ENC
    --config-dir DIR

Continue the above example:

Using svn to delete a file from your working copy merely schedules it to be deleted. When you commit, the file is deleted in the repository.

#svn delete foo.c
D         myfile

#svn commit -m "Deleted file 'myfile'."
Deleting       foo.c
Transmitting file data .
Committed revision 7.

Deleting a URL, however, is immediate, so you have to supply a log message:

#svn delete -m "Deleting file 'yourfile'" file:///tmp/repos/test/yourfile

Committed revision 8.

Here's an example of how to force deletion of a file that has local mods:

#svn delete over-there
svn: Attempting restricted operation for modified resource
svn: Use --force to override this restriction
svn: 'over-there' has local modifications

#svn delete --force over-there
D         over-there

#svn status


svn status. This command prints the status of working directories and files. If you have made local changes, it'll show your locally modified items. If you use the --verbose switch, it will show revision information on every item. With the --show-updates (-u) switch, it will show any server out-of-date information.

You should always do a manual svn status --show-updates before trying to commit
changes in order to check that everything is OK and ready to go.



For more details, please refer http://svnbook.red-bean.com/en/1.2/index.html

Monday, October 8, 2012

IP Tables with Ubuntu

Iptables is a firewall, installed by default on all official Ubuntu distributions (Ubuntu, Kubuntu, Xubuntu).

Default Configurations

When you install Ubuntu, iptables is there, but it allows all traffic by default.

List your current iptables configuration

Please enter the below command.

#sudo iptables -L

If you have just set up your server or if your configuration is in default state, you will have no rules, and you should see:







 

 

 

Allowing Established Sessions

To allow the established sessions to receive traffics, enter the below command (Below rule has no spaces either side of the comma in ESTABLISHED,RELATED)

#sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

If the above rule is not working, please use the below rule:

#sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

To check whether the above configuration is successfully applied, enter

#sudo iptables -L

You will get the below output.







 

Allowing Incoming Traffic on Specific Ports


When ever you planning to block traffic, if you are working remotely through a ssh session, first allow ssh traffic. To allow incoming traffic on the default SSH port (22), you could tell iptables to allow all TCP traffic on that port to come in.

#sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

-A - Append this rule to a rule chain.  Valid chains for what we're doing are INPUT, FORWARD and OUTPUT, but we mostly deal with INPUT in this tutorial, which affects only incoming traffic.
-p - The connection protocol used.
--dport - The destination port(s) required for this rule.  A single port may be given, or a range may be given as start:end, which will match all ports from start to end, inclusive.
-j - Jump to the specified target. By default, iptables allows four targets:
    ACCEPT - Accept the packet and stop processing rules in this chain.
    REJECT - Reject the packet and notify the sender that we did so, and stop processing rules in this chain.
    DROP - Silently ignore the packet, and stop processing rules in this chain.
    LOG - Log the packet, and continue processing more rules in this chain. Allows the use of the --log-prefix and --log-level options.


To check whether the above configuration is successfully applied, enter

#sudo iptables -L

You will get the below output.











Below rule will allow all incoming http traffic.

#sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

For an example, if you are planning to configure iptables for a web server, above two rules is to allow ssh, www traffic.

Blocking Traffic

Always the default method is to apply rules based on the top-down approach. Once a decision is made to accept a packet, no more rules affect it. As your rules allowing ssh and web traffic come first, as long as your rule to block all traffic comes after them, you can still accept the traffic you want. All you need to do is put the rule to block all traffic at the end.

Below command is to add default deny rule to the end. Because the below rule don't specify an interface or a protocol, any traffic for any port on any interface is blocked, except for web and ssh.

#sudo iptables -A INPUT -j DROP

When you follow the above step you are going to block the loopback interface also. You can write the drop rule for just eth0 by specifying -i eth0.

#sudo iptables -A INPUT -i eth0 -j DROP






To allow traffic for the loopback port, you can now append a rule. But If you append this rule, it will come too late - after all the traffic has been dropped. You need to insert this rule before that. The below command inserts it as the second rule for the list.

#sudo iptables -I INPUT 2 -i lo -j ACCEPT



2 - of the above rule specify that this rule should be added as the second rule for the allowed list.

To view the configuration, use the below command

#sudo iptables -L -v

The output would look like below.







Logging


In the above examples none of the traffic will be logged. If you would like to log dropped packets to syslog, this would be the quickest way:

#sudo iptables -I INPUT 5 -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7


Saving iptables


If you were to reboot your machine right now, your iptables configuration would disappear. Rather than type this each time you reboot, however, you can save the configuration, and have it start up automatically. To save the configuration, you can use iptables-save and iptables-restore.

Save your firewall rules to a file

#sudo sh -c "iptables-save > /etc/iptables.rules"


At this point you have several options. You can make changes to /etc/network/interfaces or add scripts to /etc/network/if-pre-up.d/ and /etc/network/if-post-down.d/ to achieve similar ends. The script solution allows for slightly more flexibility.

Solution #1 - /etc/network/interfaces

(NB: be careful - entering incorrect configuration directives into the interface file could disable all interfaces, potentially locking you out of a remote machine.)

Modify the /etc/network/interfaces configuration file to apply the rules automatically. You will need to know the interface that you are using in order to apply the rules - if you do not know, you are probably using the interface eth0, although you should check with the following command first to see if there are any wireless cards:

iwconfig

If you get output similar to the following, then you do not have any wireless cards at all and your best bet is probably eth0.

lo        no wireless extensions.

eth0      no wireless extensions.

When you have found out the interface you are using, edit (using #sudo) your /etc/network/interfaces:

#sudo nano /etc/network/interfaces

When in the file, search for the interface you found, and at the end of the network related lines for that interface, add the line:

pre-up iptables-restore < /etc/iptables.rules

You can also prepare a set of down rules, save them into second file /etc/iptables.downrules and apply it automatically using the above steps:

post-down iptables-restore < /etc/iptables.downrules

A fully working example using both from above:

auto eth0
iface eth0 inet dhcp
  pre-up iptables-restore < /etc/iptables.rules
  post-down iptables-restore < /etc/iptables.downrules

You may also want to keep information from byte and packet counters.

#sudo sh -c "iptables-save -c > /etc/iptables.rules"

The above command will save the whole rule-set to a file called /etc/iptables.rules with byte and packet counters still intact.

Solution #2 /etc/network/if-pre-up.d and ../if-post-down.d

NOTE: This solution uses iptables-save -c to save the counters. Just remove the -c to only save the rules.

Alternatively you could add the iptables-restore and iptables-save to the if-pre-up.d and if-post-down.d directories in the /etc/network directory instead of modifying /etc/network/interface directly.

The script /etc/network/if-pre-up.d/iptablesload will contain:

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

and /etc/network/if-post-down.d/iptablessave will contain:

#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.downrules ]; then
   iptables-restore < /etc/iptables.downrules
fi
exit 0

Then be sure to give both scripts execute permissions:

#sudo chmod +x /etc/network/if-post-down.d/iptablessave
#sudo chmod +x /etc/network/if-pre-up.d/iptablesload