Natting - A little bit about Hair-Pin NAT ...

In the below network topology a web server behind a router is on private IP address space, and the router performs NAT to forward traffic to its public IP address to the web server behind it.



The NAT configuration would look like below:

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade

When a client out on the Internet with IP address 2.2.2.2 establishes a connection to the web server, the router performs NAT as configured.

1. the client sends a packet with a source IP address of 2.2.2.2 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 2.2.2.2.
3. the server replies to the client's request and the reply packet has a source IP address of 192.168.1.2 and a destination IP address of 2.2.2.2.
4. the router determines that the packet is part of a previous connection and undoes the destination NAT, and puts the original destination IP address into the source IP address field. The destination IP address is 2.2.2.2, and the source IP address is 1.1.1.1.

The client receives the reply packet it expects, and the connection is established.
When a client on the same internal network as the web server requests a connection to the web server's public IP address, the connection breaks.

1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
3. the server replies to the client's request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.

The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.
To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with - if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.2 protocol=tcp dst-port=80 \
  out-interface=LAN action=masquerade

With that additional rule, the flow now changes:

1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. It also source NATs the packet and replaces the source IP address in the packet with the IP address on its LAN interface. The destination IP address is 192.168.1.2, and the source IP address is 192.168.1.1.
3. the web server replies to the request and sends the reply with a source IP address of 192.168.1.2 back to the router's LAN interface IP address of 192.168.1.1.
4. the router determines that the packet is part of a previous connection and undoes both the source and destination NAT, and puts the original destination IP address of 1.1.1.1 into the source IP address field, and the original source IP address of 192.168.1.10 into the destination IP address field.

The client receives the reply packet it expects, and the connection is established.
However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client's real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.
This is called - among other terms - hair pin NAT because the traffic flow has clients enter the router through the same interface it leaves through, which when drawn looks like a hair pin.


Reference from MicroTik Docs web source.

How to secure a LAMP server on CentOS or RHEL

LAMP is a software stack composed of Linux (an operating system as a base layer), Apache (a web server that "sits on top" of the OS), MySQL (or MariaDB, as a relational database management system), and finally PHP (a server-side scripting language that is used to process and display information stored in the database).

 

In this article we will assume that each component of the LAMP stack is already up and running, and will focus exclusively on securing the LAMP server(s). We must note, however, that server-side security is a vast subject, and therefore cannot be addressed adequately and completely in a single article.
 

In this post, we will cover the essential must-do's to secure each part of the stack.

Securing Linux

Since you may want to manage your CentOS server via ssh, you need to consider the following tips to secure remote access to the server by editing the /etc/ssh/sshd_config file.
 

1) Use key-based authentication, whenever possible, instead of basic authentication (username + password) to log on to your server remotely. We assume that you have already created a key pair with your user name on your client machine and copied it to your server.
 

1 2 3

PasswordAuthentication no RSAAuthentication yes PubkeyAuthentication yes

2) Change the port where sshd will be listening on. A good idea for the port is a number higher than 1024:
 

1

Port XXXX

3) Allow only protocol 2:

1	Protocol 2

4) Configure the authentication timeout, do not allow root logins, and restrict which users may login, via ssh:

1 2 3

LoginGraceTime 2m PermitRootLogin no AllowUsers gacanepa

5) Allow only specific hosts (and/or networks) to login via ssh:

In the /etc/hosts.deny file:

1

sshd: ALL

In the /etc/hosts.allow file:

1	sshd: XXX.YYY.ZZZ. AAA.BBB.CCC.DDD

where XXX.YYY.ZZZ. represents the first 3 octets of an IPv4 network address and AAA.BBB.CCC.DDD is an IPv4 address. With that setting, only hosts from network XXX.YYY.ZZZ.0/24 and host AAA.BBB.CCC.DDD will be allowed to connect via ssh. All other hosts will be disconnected before they even get to the login prompt, and will receive an error like this:
 

 

(Do not forget to restart the sshd daemon to apply these changes: service sshd restart).

We must note that this approach is a quick and easy -but somewhat rudimentary- way of blocking incoming connections to your server. For further customization, scalability and flexibility, you should consider using plain iptables and/or fail2ban.

Securing Apache

1) Make sure that the system user that is running Apache web server does not have access to a shell:

# grep -i apache /etc/passwd

If user apache has a default shell (such as /bin/sh), we must change it to /bin/false or /sbin/nologin:

# usermod -s /sbin/nologin apache

The following suggestions (2 through 5) refer to the /etc/httpd/conf/httpd.conf file:

2) Disable directory listing: this will prevent the browser from displaying the contents of a directory if there is no index.html present in that directory.

Delete the word Indexes in the Options directive:

1 2 3 4 5

# The Options directive is both complicated and important.  Please see # http://httpd.apache.org/docs/2.2/mod/core.html#options # for more information. # Options Indexes FollowSymLinks

Should read:

1	Options None

In addition, you need to make sure that the settings for directories and virtual hosts do not override this global configuration.

Following the example above, if we examine the settings for the /var/www/icons directory, we see that "Indexes MultiViews FollowSymLinks" should be changed to "None".

<Directory "/var/www/icons"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>	<Directory "/var/www/icons"> Options None AllowOverride None Order allow,deny Allow from all </Directory>
Before	After

3) Hide Apache version, as well as module/OS information in error (e.g. Not Found and Forbidden) pages.

1 2	ServerTokens Prod # This means that the http response header will return just "Apache" but not its version number ServerSignature Off # The OS information is hidden

4) Disable unneeded modules by commenting out the lines where those modules are declared:

TIP: Disabling autoindex_module is another way to hide directory listings when there is not an index.html file in them.

5) Limit HTTP request size (body and headers) and set connection timeout:

Directive	Context	Example and meaning
LimitRequestBody	server config, virtual host, directory, .htaccess	Limit file upload to 100 KiB max. for the uploads directory: 1 2 3 <Directory "/var/www/test/uploads">    LimitRequestBody 102400 </Directory> This directive specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2GB) that are allowed in a request body.
LimitRequestFieldSize	server config, virtual host	Change the allowed HTTP request header size to 4KiB (default is 8KiB), server wide: 1 LimitRequestFieldSize 4094 This directive specifies the number of bytes that will be allowed in an HTTP request header and gives the server administrator greater control over abnormal client request behavior, which may be useful for avoiding some forms of denial-of-service attacks.
TimeOut	server config, virtual host	Change the timeout from 300 (default if no value is used) to 120: 1 TimeOut 120 Amount of time, in seconds, the server will wait for certain events before failing a request.

For more directives and instructions on how to set them up, refer to the Apache docs.

Securing MySQL Server

We will begin by running the mysql_secure_installation script which comes with mysql-server package.

1) If we have not set a root password for MySQL server during installation, now it's the time to do so, and remember: this is essential in a production environment.

The process will continue:

 

2) Remove the anonymous user:

3) Only allow root to connect from localhost:

4) Remove the default database named test:

5) Apply changes:

6) Next, we will edit some variables in the /etc/my.cnf file:

1 2 3 4

[mysqld] bind-address=127.0.0.1 # MySQL will only accept connections from localhost local-infile=0 # Disable direct filesystem access log=/var/log/mysqld.log # Enable log file to watch out for malicious activities

Don't forget to restart MySQL server with 'service mysqld restart'.

Now, when it comes to day-to-day database administration, you'll find the following suggestions useful:

• If for some reason we need to manage our database remotely, we can do so by connecting via ssh to our server first to perform the necessary querying and administration tasks locally.
• We may want to enable direct access to the filesystem later if, for example, we need to perform a bulk import of a file into the database.
• Keeping logs is not as critical as the two things mentioned earlier, but may come in handy to troubleshoot our database and/or be aware of unfamiliar activities.
• DO NOT, EVER, store sensitive information (such as passwords, credit card numbers, bank PINs, to name a few examples) in plain text format. Consider using hash functions to obfuscate this information.
• Make sure that application-specific databases can be accessed only by the corresponding user that was created by the application to that purpose:

To adjust access permission of MySQL users, use these instructions.

First, retrieve the list of users from the user table:

gacanepa@centos:~$ mysql -u root -p
 

Enter password: [Your root password here]
mysql> SELECT User,Host FROM mysql.user;

 

Make sure that each user only has access (and the minimum permissions) to the databases it needs. In the following example, we will check the permissions of user db_usuario:

mysql> SHOW GRANTS FOR 'db_usuario'@'localhost';
 

You can then revoke permissions and access as needed.

Securing PHP

Since this article is oriented at securing the components of the LAMP stack, we will not go into detail as far as the programming side of things is concerned. We will assume that our web applications are secure in the sense that the developers have gone out of their way to make sure that there are no vulnerabilities that can give place to common attacks such as XSS or SQL injection.

1) Disable unnecessary modules:

We can display the list of current compiled in modules with the following command: php -m

And disable those that are not needed by either removing or renaming the corresponding file in the /etc/php.d directory.

For example, since the mysql extension has been deprecated as of PHP v5.5.0 (and will be removed in the future), we may want to disable it:

# php -m | grep mysql
# mv /etc/php.d/mysql.ini /etc/php.d/mysql.ini.disabled
 

2) Hide PHP version information:

# echo "expose_php=off" >> /etc/php.d/security.ini [or modify the security.ini file if it already exists]
 

3) Set open_basedir to a few specific directories (in php.ini) in order to restrict access to the underlying file system:
 

4) Disable remote code/command execution along with easy exploitable functions such as exec(), system(), passthru(), eval(), and so on (in php.ini):
 

1 2 3

allow_url_fopen = Off allow_url_include = Off disable_functions = "exec, system, passthru, eval"

Summing Up

1) Keep packages updated to their most recent version (compare the output of the following commands with the output of 'yum info [package]'):

The following commands return the current versions of Apache, MySQL and PHP:

# httpd -v
# mysql -V (capital V)
# php -v

Then 'yum update [package]' can be used to update the package in order to have the latest security patches.
 

2) Make sure that configuration files can only be written by the root account:

# ls -l /etc/httpd/conf/httpd.conf
# ls -l /etc/my.cnf
# ls -l /etc/php.ini /etc/php.d/security.ini

3) Finally, if you have the chance, run these services (web server, database server, and application server) in separate physical or virtual machines (and protect communications between them via a firewall), so that in case one of them becomes compromised, the attacker will not have immediate access to the others. If that is the case, you may have to tweak some of the configurations discussed in this article. Note that this is just one of the setups that could be used to increase security in your LAMP server.

Referred from Open source article ....

How to install LAMP stack (Apache, MariaDB/MySQL and PHP) on CentOS

 

 LAMP stack is a popular server-side software stack which is used to build and run dynamic web sites and web applications on Linux platforms. The LAMP stack is composed of Apache (as an HTTP server), MariaDB or MySQL (as a database backend), and PHP, Perl or Python (as a server-side programming language), and hence the acronym "LAMP." Other variants of the LAMP stack exist, such as LEMP (nginx, MySQL, PHP), LAPP (Apache, PostgreSQL, PHP), LLPR (Lighttpd, PostgreSQL, Ruby on Rails), and so forth.

 

 

 

 

In this tutorial, I describe how to install and set up the LAMP stack with Apache, MariaDB/MySQL and PHP on CentOS server. This tutorial is applicable to CentOS 6 as well as CentOS 7 platforms.

Step One: Apache HTTP Server

As the first step, let's install Apache HTTP server on CentOS. We will also do basic configuration for Apache server afterwards, such as adding Apache service to auto-start list, and opening an HTTP port in the firewall.

Install Apache HTTP Server

$ sudo yum install httpd

Start Apache HTTP Server and Configure Firewall

On CentOS 6.0 and 7.0:

$ sudo systemctl start httpd
$ sudo systemctl enable httpd
$ sudo firewall-cmd --zone=public --add-port=80/tcp --permanent
$ sudo firewall-cmd --reload

On CentOS 6:

$ sudo service httpd start
$ sudo chkconfig httpd on
$ sudo iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
$ sudo service iptables save

Test Apache HTTP Server

To test the installation, check if httpd daemon is up and running successfully.

On CentOS 7 or onward:

$ sudo systemctl status httpd

 

 

On CentOS 6:

$ sudo service httpd status

httpd (pid  2069) is running...

After confirming the status of httpd, open a web browser, and go to http://<web-server-ip-address> to see if you can load the default Apache web page. The screenshot below shows the default Apache web page on CentOS 6 (192.168.1.8) and CentOS 7 (192.168.1.11).

 

Note that the default document root directory of httpd is /var/www/html on both CentOS 6 and 7. Let's move on to the next step.

Step Two: MariaDB/MySQL

The next step is to set up a database backend for the LAMP stack, for which we have two choices: MySQL and MariaDB. While CentOS/RHEL 6 ships with MySQL server/client packages, CentOS/RHEL 7 moves away from MySQL, and instead offers MariaDB, a community-developed fork of MySQL, as a default database.

 

Below is how to install MariaDB/MySQL server, and set it up to start automatically upon boot.

On CentOS 7:

$ sudo yum install mariadb-server
$ sudo systemctl start mariadb
$ sudo systemctl enable mariadb

On CentOS 6:

 

Install MySQL server/client package, and start MySQL server as follows. 

$ sudo yum install mysql-server
$ sudo service mysqld start
$ sudo chkconfig mysqld on

 

As MariaDB and MySQL are compatible with each other in terms of APIs and command-line usage, the LAMP stack can be configured and operated pretty much the same way regardless of whether you choose MariaDB or MySQL.

 

As a security precaution, run the following add-on script which is included in the MariaDB/MySQL server package.

 

$ sudo mysql_secure_installation

 

 

This script will reconfigure the database server for server hardening purposes. For example, it will change (empty) root password, remove anonymous user, disallow remote root login, and remove a default test database.

Step Three: PHP

The last step in setting up the LAMP stack is to install PHP, a server-side scripting language which is responsible for creating dynamic web pages for users. At a minimum, the LAMP stack requires the following two packages installed.

 

$ sudo yum install php php-mysql

 

The php package adds PHP support to Apache HTTP server, and the php-mysql package allows PHP applications to access MariaDB/MySQL server. Besides those two required packages, there are many other useful PHP modules you can install depending on your requirements. For example:

• php-gd: needed for image processing in PHP applications.
• php-odbc: needed for ODBC database access in PHP applications.
• php-pecl-memcache: needed when setting up Memcached caching daemon.
• php-pgsql: needed for PostgreSQL database access in PHP applications.
• php-snmp: needed for querying SNMP-managed devices in PHP applications.
• php-xml: needed for parsing XML in PHP applications.
• php-soap: needed to support SOAP protocol in PHP applications.
• php-xmlrpc: needed to support XML-RPC protocol in PHP applications.

 

You can get a full list of available PHP modules by running:

$ yum search php-

 

Next, let's change the default timezone used by PHP applications. You will need to find out your timezone by using tzselect command.

 

$ tzselect

 

 

After you answer a series of questions, the tzselect will print out your timezone string (e.g., "America/New_York"). Open /etc/php.ini file with a text editor, and add the following line.

date.timezone = "America/New_York"

Don't forget to restart httpd after installing PHP.

 

On CentOS 7:

$ sudo systemctl restart httpd

 

On CentOS 6:

$ sudo service httpd restart

Finally, let's check whether PHP is working properly. For this, use the following command, and check if the output of phpinfo() shows up correctly.

 

$ php -r "phpinfo();" | more

 

Once you verify PHP command-line output, let's create a test PHP file as follows, and verify that the PHP file is loaded successfully by Apache HTTP server.

$ sudo vi /var/www/html/test.php

1	<?php phpinfo(); ?>

Go to http://<web-server-ip-address>/test.php in your web browser. You should see the following output.

 

Now you have successfully set up the LAMP stack!

 

How to set up Samba as a Primary Domain Controller ...

How to set up Samba as a Primary Domain Controller   

A domain controller is a server which groups multiple computers to centralize their authentication system. When you are using a domain controller, you don't login to your computer, but instead login to the domain controller. Every authentication request is handled by the Primary Domain Controller (PDC).

 

Usually you hear about PDC using a Windows based server. In this tutorial, I'll describe how to set up a PDC using Samba, which is based on Linux.

 

There are four main steps for setting up Samba as a PDC:

• Install Samba
• Configure /etc/samba/smb.conf
• Add domain users
• Register all Windows computers with Samba PDC.

1. Samba Installation

If you are using a Debian based Linux, run the following command on the terminal window to install Samba:

$ sudo apt-get install samba
$ sudo apt-get install samba-common
$ sudo apt-get install samba-common-bin

 

If you are using a Red Hat based Linux, you may use rpm or yum package manager to install Samba.

2. Samba Configuration

The main configuration of Samba server is found in /etc/samba/smb.conf. For a PDC server, there are three part of the file which you need to configure: global, netlogon, and homes.
Before you start modifying the configuration file, I suggest you back up the existing Samba configuration file.

$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.old

Configuring [global] parameters

[global]
 workgroup = sambadomain 
 netbios name = sambapdc 
 server string = Samba PDC 
 domain master = yes 
 preferred master = yes 
 domain logons = yes 
 add machine script = /usr/sbin/useradd -N -g machines -c Machine -d /var/lib/samba -s /bin/false %u 
 security = user 
 encrypt passwords = yes 
 wins support = yes 
 name resolve order = wins lmhosts hosts bcast 

 logon path = \\%N\%U\profile 
 logon drive = H: 
 logon home = \\%N\%U

Change the names of the workgroup and the PDC according to your environment, so that they correspond to the actual values in your network. If you have another Wins server on your network, remove "wins support = yes", because having more than one causes a problem. "wins support = yes" means Samba acting as a Netbios server.

Creating LMHOSTS file

Don't forget to register your domain IP address to the LMHOSTS file. The LMHOSTS file is a mapper between the IP address of the domain controller and Netbios name. When you add a Windows computer to the SAMBADOMAIN, Windows tries to find the PDC's IP address. If Windows fails to find the PDC's IP address, then you won't be able to register a computer with the PDC.
The LMHOSTS file should be created and placed in /etc/samba/lmhosts. The content of LMHOSTS file is similar to /etc/resolv.conf file, except that you need to register the Netbios name instead of the host name. For example, if your PDC has an IP address 10.10.101.1 with sambadomain as workgroup name, and sambapdc as the Netbios name, the content of the lmhosts file should look like the following:

10.10.101.1 sambadomain
10.10.101.1 sambapdc

After creating /etc/samba/lmhosts, re-run the nmbd daemon as follows:

$ sudo nmbd -H /etc/samba/lmhosts -D

Configuring [netlogon] parameters

[netlogon]
 path = /var/lib/samba/netlogon 
 browseable = no 
 read only = no 
 create mask = 0700 
 directory mask = 0700 
 valid users = %S 

/var/lib/samba/netlogon is a startup directory for PDC logon. When users login to the Samba PDC, a script called netlogon.bat in the directory will be executed.

$ sudo mkdir -m 0755 /var/lib/samba/netlogon

 

For example, if you want to automatically mount a network drive from the PDC, Create the following netlogon.bat script in /var/lib/samba/netlogon

1 2	## Samba Logon Script net use x: \\sambapdc\share

Configuring [homes] parameters

This is a configuration file for PDC user's home directory.

[homes]
 valid users = %S 
 guest ok = yes 
    read only = yes 

Testing the configuration file

After saving all configuration files, test your configuration with the following command:

$ sudo testparm

If there is any syntax error detected, fix it and restart Samba.

3. Adding Domain Users

Adding admin user and group for the PDC

In Linux, admin user is the root user. So you need to run the following command to add the root user as the Samba admin:

$ sudo smbpasswd root

You should not use the same password as the Linux root user.

Create a machines group

The next step is to create a group called "machines".

$ sudo groupadd -g machines

Samba will automatically add users to this group, as long as you configure "add machine script" correctly in [global] section in /etc/samba/smb.conf.

Create a Linux Account for PDC login

You need to create a user on PDC for domain login. In this example, I will create an account that disables Linux login. So every access to the PDC must be done via Samba.
For example, creating user "arsalan":

$ sudo smbpasswd -a arsalan

Enter the same password twice.
You need to activate the user with the following command:

$ sudo smbpasswd -e dan

Grant user "arsalan" to login to the PDC:

$ sudo net rpc rights grant "SAMBADC\dan" SeMachineAccountPrivilege SePrintOperatorPrivilege SeAddUsersPrivilege SeDiskOperatorPrivilege SeRemoteShutdownPrivilege

$ sudo net groupmap add ntgroup="Administrator" unixgroup=root rid=512 type=d

4. Register Windows Computers with the Samba PDC

Under Windows computer properties, change the domain name to sambadomain. Reboot your Windows PC, and try to login with SAMBADC/arsalan. If you successfully login, then your Samba PDC is ready.

Referred from open source article

How to set up a Samba file server to use with Windows clients

   

According to the Samba project web site, Samba is an open source/free software suite that provides seamless file and print services to SMB/CIFS clients. Unlike other implementations of the SMB/CIFS networking protocol (such as LM Server for HP-UX, LAN Server for OS/2, or VisionFS), Samba (along with its source code) is freely available (at no cost to the end user), and allows for interoperability between Linux/Unix servers and Windows/Unix/Linux clients.

For these reasons, Samba is the preferred solution for a file server in networks where different operating systems (other than Linux) coexist - the most common setup being the case of multiple Microsoft Windows clients accessing a Linux server where Samba is installed, which is the situation we are going to deal with in this article.

 

Please note that on the other hand, if our network consists of only Unix-based clients (such as Linux, AIX, or Solaris, to name a few examples), we can consider using NFS (although Samba is still an option in this case), which has greater reported speeds.

 

Installing Samba in Debian and CentOS/Redhat

Before we proceed with the installation, we can use our operating system's package management system to look for information about Samba:

On Debian:

# aptitude show samba

 

On CentOS:

# yum info samba

 

In the following screenshot we can see the output of 'aptitude show samba' ('yum info samba' yields similar results):

Now let's install Samba (the screenshot below corresponds to the installation on a Debian 7 [Wheezy] server):

On Debian:

# aptitude install samba

 

On CentOS:

# yum install samba 

 

Adding Users to Samba

For versions earlier than 4.x, a local Unix account is required for adding users to Samba:

# adduser -s /dev/null -m -d /home/<username> <username>

Next, we need to add the user to Samba using the smbpasswd command with the '-a' option, which specifies that the username following should be added to the local smbpasswd file. We will be prompted to enter a password (which does not necessarily have to be the same as the password of the local Unix account):

# smbpassword -a <username>

 

Finally, we will give access to user xmodulo to a directory within our system that will be used as a Samba share for him (and other users as well, if needed). This is done by opening the /etc/samba/smb.conf file with a text editor (such as Vim), navigating to the end of the file, and creating a section (enclose name between square brackets) with a descriptive name, such as [xmodulo]:

# SAMBA SHARE [xmodulo] path = /home/xmodulo available = yes valid users = xmodulo read only = no browseable = yes public = yes writeable = yes

We must now restart Samba and -just in case- check the smb.conf file for syntax errors with the testparm command:

# service samba restart
# testparm

 

Imp Note: If there are any errors, they will be reported when testparm ends.

Mapping the Samba Share as a Network Drive on a Win 7 PC

Right click on Computer, and select "Map network drive":



Type the IP address of the machine where Samba is installed, followed by the name of the share (this is the name that is enclosed between single brackets in the smb.conf file), and make sure that the "Connect using different credentials" checkbox is checked:



Enter the username and password that were set with 'smbpasswd -a' earlier:

Go to Computer and check if the network drive has been added correctly:

 

As a test, let's create a pdf or any other file with folder from the main page of Samba, and save it in the /home/xmodulo directory:



Next, we can verify that the file is accessible from Windows:



And we can open it using our default pdf reader:



Finally, let's see if we can save a file from Windows in our newly mapped network drive. We will open the change.log file that lists the features of Notepad++:



and try to save it in Z:\ as a plain text file (.txt extension); then let's see if the file is visible in Linux:

Enabling quotas

Quota definition is very easy one to do. As a first step, we need to verify whether the current kernel has been compiled with quota support:

# cat /boot/config-$(uname -r) | grep -i config_quota

 

Each file system has up to five types of quota limits that can be enforced on it: user soft limit, user hard limit, group soft limit, group hard limit, and grace time.
We will now enable quotas for the /home file system by adding the usrquota and grpquota mount options to the existing defaults option in the line that corresponds to the /home filesystem in the /etc/fstab file, and we will remount the file system in order to apply the changes:



Next, we need to create two files that will serve as the databases for user and group quotas: aquota.user and aquota.group, respectively, in /home. Then, we will generate the table of current disk usage per file system with quotas enabled:

# quotacheck -cug /home
# quotacheck -avugm

 

Even though we have enabled quotas for the /home file system, we have not yet set any limits for any user or group. Check for quota information for existing user/group:

# quota -u <username>
 # quota -g <groupname>

 

Finally, the last couple of steps consist of assigning the quotas per user and / or group with the quotatool command (note that this task can also be performed by using edquota, but quotatool is more straightforward and less error-prone).

To set the soft limits to 4 MB and the hard limit to 5 MB for the user called xmodulo, and 10 MB / 15 MB for the xmodulo group:

 

# quotatool -u xmodulo -bq 4M -l '5 Mb' /home
# quotatool -g xmodulo -bq 10M -l '15 Mb' /home

 

And we can see the results in Windows 7 (3.98 MB free of 4.00 MB):

 

Referenced from Gabriel Cánepa  , Linux Sys Administrator 
He is a GNU/Linux sysadmin and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work.