Tag Archive : freebsd

/ freebsd

Installing FreeBSD Using Remote SSH Session

December 9, 2015 | Article | No Comments

FreeBSD is a powerful open-source operating system based on BSD Unix and developed by a large scale community.

You can install FreeBSD using direct access to a machine. This means, you have physical access to the machine such as operate keyboard, see the display on monitor directly, etc. In short, you are not using any medium to install and configure your machine. This is normal circumstance. But there is another method we can do, instead of installing FreeBSD by using physical access we can do indirect installation. The method we discuss is installation using remote SSH session. This article will cover how to do it.

Of course, you still need a Live CD (or live CD image, if you install for Virtual Machine). The one I use is FreeBSD-9.10RELEASE-amd64-dvd1.iso. Other than that, I use VirtualBox 4.2.6 for testing.

Despite of the fact we use virtual machine, this method should work on any machine.

Intro & Preparation

Boot the DVD (or the ISO). A bunch of text will appear in front of you. Ignore it if it doesn’t give you error.

On the welcome screen, you will have three options: < Install >, < Shell >, and < Live CD >. Choose the < Live CD > option. You will then be brought to a login screen (in CLI mode, of course). Enter “root” as username and no password required.

If you use non-English keyboard, invoke “sysinstall” tool to configure your keyboard mapping. In sysinstall, go to “Configure / Console / Keymap”.

If you use VirtualBox, VMWare, or other virtualization, make sure you have your machine connected with Bridged adapter (or something like that) not under NAT. This way, you can directly access your machine because the IP address will be on the same network as you.

Temporary /etc

Before starting SSH daemon, we have to create a writeable /etc space. We are using unionfs so that we could write on top of non-writable disk.

mkdir /tmp/etc
mount_unionfs /tmp/etc /etc

SSH Configuration

Configure SSH daemon to allow remote login.

ee /etc/ssh/sshd_config

Find a line with “PermitRootLogin” and make sure it was written like this:

PermitRootLogin yes

Then start the daemon.

/etc/rc.d/sshd onestart

You should also set the root password so that you can login.

passwd root

Network Configuration

There are two ways to configure network: manual configuration, automatic configuration.

Manual Configuration

This way, you want to configure IP address and other stuff manually. This is useful if you don’t have DHCP server in network. What you need is the free/unused IP address on your network, the netmask, and the default gateway on network.

Suppose you want to use 192.168.1.103 as your machine’s address with netmask 255.255.255.0 or /24 and the gateway 192.168.1.1.

ifconfig em0 inet 192.168.1.103 netmask 255.255.255.0 up
route add default 192.168.1.1

Automatic Configuration

This way, you want to configure IP address and other stuff automatically. This method rely on DHCP server in network, either by your router, or another specific machine.

dhclient em0

How to Connect

You can connect to soon-to-be-installed-with-FreeBSD machine by using usual ssh connection. For example you are using Linux:

ssh [email protected]

Then, you can continue to installation process by invoking

bsdinstall

File Transfer using Rsync

December 9, 2015 | Article | No Comments

Rsync, old but still powerful tools for moving files between hosts. The main use is to keep file trees synchronized. Rsync have been used for long time since its inception. And it seems Rsync is still used this day.

Rsync is available in many platform, especially UNIX-like system. As the title said, we will discuss about Rsync and not nailed to specific Operating System. In this article we are not discussing about how to install rsync so I assume we already have rsync installed on local machine.

We also not covering about how to prepare rsync server. It will be discussed in another article.

Rsync Overview

Rsync syntax in general would be:

rsync [OPTION] SRC DST

Where SRC is the source address and DST is the destination.

In general, we can use rsync for some purposes:

    1. Copying local files.
    2. Copying from local machine to remote machine.
    3. Copying from remote machine to local machine.

Synchronize local directory and remote rsync server.

On next sections, we will discuss each way described above. But our topic will be focused to point (2) to (4). Well, why would we use rsync to copying local files instead of using cp command?

It is also recommended to used rsync over ssh. Rsync does not provide any security while transferring data therefore we need to tunnel it with secure remote connection.

Now, some arguments or command options we will used in this article:

  • –delete: delete files that don’t exists on sender (system)
  • -v: verbose, use -vv for more detailed information
  • -e “ssh options”: specify ssh as remote shell. The “options” will then passed to ssh when creating a connection
  • -a: archive mode
  • -r: recurse into directories
  • -z: compress file data. Might consume memory and cpu resource but helpful for low bandwidth.

Copying from Local Machine to Remote Machine

Also known as push / upload file(s) into remote machine. Suppose we want to copy /var/www/backup.tgz to a remote server called backup.celestial-links.net on home directory, we could use:

rsync -v -e ssh /var/www/backup.tgz [email protected]:~

You will then be prompted by a password authentication message.

Copying from Remote Machine to Local Machine

Also known as pull / download file(s) from remote machine. Suppose we want to copy /usr/bin/secretbackdoor from remote server machine.celestial-being.net to local storage /tmp:

rsync -v -e ssh [email protected]:/usr/bin/secretbackdoor /tmp/

Synchronizing Local Directory and Remote RSync Server

Well, this is the main purpose of rsync (guess where rsync name comes from). Here the methods are two way connection, it means both machine will synchronizing their content.

rsync -r -a -v --delete rsync://rsync.celestial-links.net/somedir/ /local/somedir/

Or you can swap the src and destination, its same

rsync -r -a -v /local/somedir rsync://rsync.celestial-links.net/somedir

Note that this method use pure rsync which means we are not using it on top of ssh protoocl.

If you want to only synchronize a local directory according to remote directory:

rsync -r -a -v -e "ssh -l xathrya" --delete /local/somedir backup.celestial-links.net:/somedir

Or you want to only synchronize a remote directory according to our local directory:

rsync -r -a -v -e "ssh -l xathrya" --delete backup.celestial-links.net:/somedir /local/somedir

Transfer from One Remote Machine to Other Remote Machine

Suppose we have two remote servers: A and B. In this section we will use rsync to move a file from A to B without transit to our machine. It means file on A is directly copied to B.

rsync -zavrR --delete --links usernameA:[email protected]:/path/to/resource \
usernameB:[email protected]:/path/to/resource

Using CUPS

December 9, 2015 | Article | No Comments

On previous article, we have discussed about how to install CUPS on FreeBSD. In this article we will discuss and use the server for printing example documents.

Configurations

Test the server by pointing a web browser to http://host.example.com:631 (substituting your server’s hostname or IP address for host.example.com). You will then see a Common Unix Printing System Welcome! page if the server started successfully; if you don’t, check your /usr/local/etc/cups/cupsd.conf file for typographical errors.

If you are using a PostScript printer, have its PPD (PostScript Printer Description) file handy . If you don’t have your printer’s PPD file, check http://openprinting.org.

Gutenprint Driver

The Gutenprint driver contains extensive support for Epson printers (among others). Visit http://gutenprint.sourceforge.net for a complete list of supported printers. The following commands will install the Gutenprint driver from the ports collection (this may take 30 minutes or more to complete):

cd /usr/ports/print/gutenprint
make install clean

A menu will appear containing options for Gutenprint; choose Gutenprint Cups Drivers. You may install the HPLIP driver as well, if you wish.

HPLIP Driver

The HP Linux Imaging and Printing driver was developed at Hewlett-Packard, and it contains support for virtually all HP printers. Visit http://hplip.sourceforge.net for a complete list of supported printers. The following commands will install the HPLIP printer driver from the ports collection (this may take 60 minutes or more to complete):

cd /usr/ports/print/hplip
make config; make install clean

A menu will appear containing options for HPLIP. Here we use defaults installation, thus we don’t need to change anything.

Finishing Printer Setup

Ensure that your printer is powered on and connected to the CUPS server via a USB or parallel cable. Reboot the system. Log in as root to the web administration interface https://host.example.com:631/admin (or substitute it with your servers hostname or IP address).

Select Add Printer. Choose a name for the connected printer. This name will act as identifier among printers we have. Also enter a description of the printer (e.g., HP LaserJet 1100) and then click Continue. There should be a pull-down menu on the next page. Select either USB or LPT (parallel) as appropriate and then click Continue. Select the correct brand (vendors) of your printer on the next page, then click Continue. Choose the correct model from the list presented on the next page, then click Continue. Your printer should be ready to accept print jobs. You can print a test page from the Printers page of the CUPS web interface. Proceed to the appropriate section to set up client printing.

Various Testing

Printing from Windows XP

To print to a CUPS printer from Windows XP:

  1. click the Start menu and select Control Panel.
  2. Double-click the Printers and Faxes icon.
  3. Click Add a Printer at the left side of the window. The Welcome to the Add Printer Wizard dialog will appear; click Next.
  4. Click the Network Printer radio button, then click Next.
  5. Click the Connect to a Printer on the Internet or on a Home or Office Network radio button. In the URL field, use the following syntax to specify the server address: http://host.example.com:631/printers/printername (substitute the hostname or IP address of your CUPS server for host.example.com and replace printername with the name you assigned the printer during the CUPS printer setup).
  6. After clicking Next, you will be required to select the printer series and model from a list. If you have a Windows driver from the manufacturer, use it; otherwise select it from the given list and click OK.

You should be able to print via the CUPS print server from Windows applications.

Printing from Mac OS X

Open an application capable of printing (e.g., Safari). In the File menu, select Print. Select the Printer pull-down menu to display a list of available printers. You should see Shared Printers in the lower half of the menu. Hover the mouse over Shared Printers to display the submenu. Select the appropriate CUPS printer from the list. The CUPS printer will be added to your permanent list of printers. You can print the current document by clicking Print on the lower-right side of the dialog box.

Printing from the FreeBSD Command Line

Printing from command line is one of fun thing to do. The contents of file can be printed by CUPS. To print it, use following command:

lp -d printername filename

Send Command from Command Line

Print a Document

As a user, we can use printer on network using CUPS. To print using the default print, use:

lpr filename

Print to specific printer:

lpr -P printer filename

Print multiple copies, for example 4 copies:

lpr -P filename -#4 filename

CUPS status information

Query CUPS status by:

lpr <options>

The options can be:

  • -t: show all CUPS info
  • -d: show default printer
  • -p: show all printer
  • -a: show all printers that accept jobs
  • -o: show active print jobs

Cancel a Print Job

Cancelling a job can be done by the same user who submit the job.

lprm <job-id>

Setting Options for a Specific Print Job

Sometimes, user needs specific print options. A general way to define specific options for a print job is:

lpr -P printer -o option1=value -o option2=value filename

Modify the Default Print Options

A user can define his own options for all his print jobs for a specific printer. They are saved in the ~/.lpoptions file and override the default options that have been defined by the system administrator for this specific CUPS printer.

Create Sets of Options

A user can set his own default options for a specific CUPS printer by issuing following command:

lpoptions -P printer -o option1=value -o option2=value filename

Remove Print Options

Previously defined print options can be removed from ~/.lpoptions by:

lpoptions -P printer -r option1 -r option2

List a Printer’s Options

To list print queue’s current options:

lpoptions -P printer

To list print queue’s current options:

lpoptions -P printer -1

Create Sets of Options

A very useful CUPS feature is that sets of options can be defined. These can be system-wide if they are set by root, or user specific if they are set by a user. Printer instances are extra options for a specific printer that are saved as an extra printer in the form printer/set. This virtual printer’s settings override the default options. To create a printer instance, as a user issue the command:

lpoptions -p printer/set1 -o option1=value -o option2=value

To delete a printer instance issue the command:

lpoptions -x printer/set1

The printer instance is listed as a printer in lpstat. The user can send a document to the printer instance:

lpr -P printer/set1 filename

Options Available

The common print options can be seen here. If an option accepts a value, then it is listed in the form option=value:

  • landscape – for landscape printing
  • media=A4 – check your ppd file for possible media values
  • Collate=true | false – useful when printing multiple copies
  • sides=two-sided-short-edge – used for landscape prints [the default is sides=one-sided]
  • sides=two-sided-long-edge – used for portrait prints [the default is sides=one-sided]
  • page-ranges=1-4,7,9-12 – print specific pages or page ranges
  • page-set=odd | even – print only odd or even pages
  • outputorder=normal | reverse – the pages are printed from first to last or the other way around
  • cpi=10 – characters per inch
  • lpi=6 – lines per inch
  • columns=2 – format the text in two or more columns
  • page-left=value – specify the left margin in points [1pt = 1/72inch]
  • page-right=value – specify the right margin in points [1pt = 1/72inch]
  • page-top=value – specify the top margin in points [1pt = 1/72inch]
  • page-bottom=value – specify the bottom margin in points [1pt = 1/72inch]
  • job-sheets=none – front and back cover pages
  • job-sheets=standard
  • job-sheets=classified,classified

In this article we will discuss about how to install CUPS on FreeBSD. In this article I use:

  1. FreeBSD 8.3
  2. Updated ports collection.
  3. Supported parallel or USB Printer

What is CUPS?

The Common Unix Printing System (CUPS) is an open source printing system that provides a common interface to support printers in Unix-based systems. It also provides a standardized and modular platform that allows the use of external filters like Foomatic and Ghostscript for expanded printer compatibility. CUPS is licensed under the GNU GPL and has become the standard printing system for a large number of Linux distributions as well as Mac OS X.

CUPS is composed of a print spooler, filters, and backends. It uses the Internet Printing Protocol (IPP) to accept print jobs from clients on the network. The print data is then stored in a print spool or queue until the printer is ready to accept a print job. When the printer is ready, CUPS sends the print job through filters that convert the print job data into a language the printer understands. The converted data then travels through a backend to the intended printer. Common backends include Universal Serial Bus (USB) and parallel interfaces.

Most printers communicate using either PostScript or Printer Control Language (PCL). PostScript was developed at Adobe Systems in the mid-1980s to create a standard language for both document exchange and printer communication. CUPS can print to virtually all printers that support PostScript. However, PostScript printers are notoriously expensive due to the cost of licensing the technology from Adobe. PCL was created by Hewlett-Packard in 1984 and didn’t carry the licensing restrictions of PostScript. This has created a large market of low cost PCL printers. To support this large market, projects like Gimp-Print were started to develop Unix drivers for PCL printers. HP has responded to the need for Unix-based drivers with the Hewlett-Packard Inkjet Driver Project. Gimp-Print and the HP Inkjet Driver Project greatly expand CUPS support for non-PostScript printers.

Installation

Installing CUPS is as easy as installing other ports. You can enter following commands to complete installation (use root privileges):

setenv XORG_UPGRADE yes
cd /usr/ports/print/cups
make config ; make install clean
rehash

Here we use basic / defaults options so we don’t need to change anything.

Configuration

Once the installation process is complete, it’s time to configure CUPS for use on our system.

FreeBSD includes a print spooling system that utilizes the same command names as CUPS. If the search path has not been modified from its default, the FreeBSD spooler will run instead of CUPS.  Therefore we need to tell FreeBSD to use CUPS instead of its print spooler. We also need to tell make command to skip compilation of the print spooler if we choose to recompile the base operating system and consider CUPS as drop-in replacement for the FreeBSD print spooler.

Edit /etc/make.conf and add following:

cp /etc/make.conf /etc/make.conf
echo 'NO_LPR="YES"' >> /etc/make.conf

In order to allow print clients to send raw print data to the connected printer we must uncomment a line in the /usr/local/etc/cups/mime.convs file. Scroll down to the application/octet-stream declaration and remove the hash mark (#) to uncomment the line. It should now appear as follows:

application/octet-stream   application/vnd.cups-raw     0     -

Save and exit.

We are now ready to modify the main configuration file, /usr/local/etc/cups/cupsd.conf. Now change the Listen localhost:631 declaration to Listen *:631. This allows external clients access to the CUPS web administration page. Otherwise, CUPS only serve localhost (serves self only).

By default, access to CUPS services is restricted and needs to be relaxed to enable printing support to computers on the local network. Change the Allow localhost declaration within the Location / container to Allow @LOCAL. The line should appear as follows after the modification:

# Restrict access to the server...
<Location />
   Oder allow,deny
   Allow @LOCAL
</Location>

By default, access to the administrative web interface is closed to the local network and can only be accessed from the server itself. To allow access from the local network, change the Allow localhost declaration within the Location /admin container to Allow @LOCAL. You should also add Require user @SYSTEM to require authentication for access to the web administration page. The lines should appear as follows after the modification:

# Restrict access to the admin pages..
<Location /admin>
   Encryption Required
   Require user @SYSTEM
   Order allow,deny
   Allow @LOCAL
</Location>

Note: The root account and users that are members of the wheel group will be able to log in to the web administration page at https://host.example.com:631/admin (substitute host.example.com with your server’s hostname or IP address) to manage printers and print jobs. CUPS will encrypt authentication credentials using a self-signed certificate. We can also specify our own SSL Certificate.

Autostart at Boot

To automatically start CUPS on booting, make sure cupsd is enabled in /etc/rc.conf. You invoke following command to do so:

echo 'cupsd_enable="YES"' >> /etc/rc.conf

Save and exit. Enjoy

Setting DHCP Server on FreeBSD

December 9, 2015 | Uncategorized | No Comments

In open network such as internet cafe, campus, etc, DHCP protocol is widely used. DHCP providing client an IP address without them set IP manually. DHCP server also manage what IP should and should not be used by client in a network. This will ensure a dynamic environment in a network.

In this article we will discuss about install and configuring DHCP on FreeBSD machine. Technically I use:

  1. FreeBSD amd64 8.3
  2. ISC DHCP Server

How DHCP Works

When a client system first joins a network using DHCP, it broadcasts a request to the local network for configuration information. The DHCP server then answers this request with the parameters set in the DHCP server configuration file. The client system applies this assigned configuration to its network interface in order to communicate with the network.

DHCP servers generally assign IP addresses in one of two ways: statically or dynamically. The static method allocates an IP address to a client based on the client’s hardware MAC (Media Access Control) address. This IP address will not change. A dynamic IP address assignment is a leased address. The DHCP server assigns these addresses from a pool or range set by the administrator. Dynamic IP addresses are returned to the pool when a client disconnects from the network. If the same client rejoins the network, it may be assigned a different IP address if the previously assigned address is unavailable.

Preparation

A DNS server is not necessary to run DHCP server. However if you plan on running your own DNS server, you should install and configure it before proceeding to next stage.

Make sure you have acquired and become super user to do installation.

Installation

Installing ISC DHCP Server is as easy as other ports installation. The version we use will be ISC DHCP Server version 4.2. Now do command:

cd /usr/ports/net/isc-dhcp42-server
make config
make install clean
rehash

A menu of options might appear. In this article we will use default options, so leave those options at defaults.

Configuration

Fortunately, we can use a sample configuration provided by ISC DHCP server.

cd /usr/local/etc
cp dhcpd.conf.sample dhcpd.conf

ISC DHCP server use a plain text /usr/local/etc/dhcpd.conf as its main configuration file. Edit that file and adjust as we need.

In this article we will use a scenario like this:

  1. Using domain name ns1.celestial-being.net and ns2.celestial-being.net with IP address 192.168.1.11 (this existing domain name is not necessary)
  2. The available address will be 192.168.1.100 to 192.168.1.254.
  3. We disable dynamic DNS update.
  4. The router is at 192.168.1.1

Now alter the /usr/local/etc/dhcpd.conf and adjust it with your need. This one should fulfill our need:

option domain-name "celestial-being.net";
option domain-name-servers 192.168.1.11;

authoritative;

ddns-update-style none

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.100 192.168.1.254
   option routers 192.168.1.1;
}

Make sure you terminating the line with “;” (semi-colon).

Another thing to note: there should be no other DHCP server on network. Most routers have a built-in DHCP server therefore if you want to use own DHCP server, disable the router DHCP’s before.

Whether we use ourself as a router or not, we can specify the router used by client.

At this point, we have configured a simple DHCP network.

Install and Configure a NTP Server on FreeBSD

December 9, 2015 | Article | No Comments

NTP (Network Time Protocol) is an Internet protocol used for synchronizing the clocks of networked computers. Computer clock accuracy is instrumental in providing a consistent reference for system log files, email timestamps, time-activated scripts, and so on. The NTP system is capable of keeping your computer’s clock accurate to within a few milliseconds of an accurate time server. Time servers are usually connected directly to a source of accurate time (e.g., atomic or GPS clocks).

In this article we will discuss about installing and configuring FreeBSD as NTP Server. For that purpose, I use:

  1. FreeBSD amd64 8.3

How it Works?

A server running the NTP daemon periodically synchronizes its clock to one or more established time servers. Over time, the NTP daemon calculates the system-specific clock error. If the system temporarily loses Internet connectivity, the NTP daemon will keep the system clock accurate using this error (or clock drift) data until it can re-synchronize with a time server.

Preparation

Make sure we have became superuser before proceeding to next stage.

Installation

Installation of NTP is as easy as install other ports.

cd /usr/ports/net/ntp
make config
make install clean
rehash

Configuration

At this point, we have successfully install NTP Server. Before using it, we should do a minimum configuration.

Create a drift file for storing clock correction data. In this article, we will store the drift file at /etc/ntp as drift. The drift file is used as

touch /etc/ntp/drift

Next, we will select appropriate time servers for synchronization. Choose the closest time server available to our network (geographically). The updated list of public time servers can be viewed here. This will make our server adjusting the time relative to our selected time server. Note this, and at least use three network servers.

Next, create and edit /etc/ntp.conf. This file will be our NTP’s configuration file. Later, write these into ntp.conf:

server time.example1.com iburst
server time.example2.com iburst
server time.example3.com iburst
driftfile /etc/ntp/drift
logfile /var/log/ntp.log

In above example, we use time.example1.com, time.example2.com, and time.example3.com as our network time server.

To make our NTP daemon automatically started at boot time, add following lines to /etc/rc.conf:

ntpd_enable="YES"
ntpd_program="/usr/local/bin/ntpd"

UFS Access Control Lists on FreeBSD

December 9, 2015 | Article | No Comments

Access Control List, or ACL, is a simple security mechanism but most likely implemented on any system. Not to mention, it is also implemented on various filesystem, including ext2, ext3, ext4 and also XFS.

If in earlier article we have discussed about Extended ACL in general, now we will discuss about Access Control List specific on UFS, which used by FreeBSD.

In this article I use:

  1. FreeBSD amd64 8.3
  2. UFS

ACL and POSIX

As seen on this article, traditional POSIX file system object permission model defines three classes of users: owner, group, and other. Each of these classes is associated with a set of permission.

The owner class permissions define access privileges to the object (file/folder) owner. The group refers to the owning groups and thus the group permissions defines action can be done by owning group of file. When a user is not either owner or group owner of file, s/he simply referred as other and having other permissions on the file.

The permissions are defined as read, write, and execute an object and denote as r, w, x.

An Extended-ACL consists of a set of entries. The permissions of each file system object have an ACL representation, even in the minimal. On traditional ACL, there are owner, group, and other permissions. One for each class. In Extended ACL, every class might has one or more entries defined. In ACL, default permission entries are calle minimal ACL.

Extended-ACL also contain a mask entry and may contain any number of named. user and named group entries.

So what makes Extended-ACL good? Let’s use same case as used in this article.

Extended-ACL can control permission in detail. Using Extended-ACL we can specify what user can do, or what group can do.

Let take an example of this. Let say there are three user: xathrya, marina, and elisa. All of them are on group developer. A file “secret.txt” is created and owned by xathrya. Xathrya want to restrict marina from reading the file, while elisa is restricted to writing the file. Then there is no restriction for marina to write file and elisa to read the file. Using file permission, xathrya can set the permission to 760 so only him can alter the file. But as a fellow group member, marina and elisa can also alter the file. If xathrya alter the file permission to 740, elisa is restricted from writing the file but marina is not restricted to reading. If xathrya use 720, the other condition applies.

Using Extended-ACL, xathrya can precisely set restriction on marina and elise. On account marina, xathrya can put ban for her to read while he can also put ban for elise to write. So that we can have permission -w- specific to marina and r– for elisa. This is the power of Extended-ACL.

Preparation

ACL extend the standard UNIX permission model in a higly compatible POSIX way. But to enable ACL support for UFS file system we must make sure kernel is capable to do so. You might also recompile the kernel if you don’t have enable the support yet. When you are recompiling, make sure you enable

options UFS_ACL

If this option has note been compiled in, a warning message will be displayed when attempting to mount a file system supporting ACLs. This option is included in the GENERIC kernel and is relied upon when using extended attributes.

A file / directory with ACL will show a + (plus) sign in their permission settings when viewed. For example:

drwx------  2 xathrya  wheel  512 Dec 27 11:54 private
drwxrwx---+ 2 xathrya  wheel  512 Dec 23 10:57 directory1
drwxrwx---+ 2 xathrya  wheel  512 Dec 22 10:20 directory2
drwxrwx---+ 2 xathrya  wheel  512 Dec 27 11:57 directory3
drwxr-xr-x  2 xathrya  wheel  512 Nov 10 11:54 public_html

Here we see directory1, directory2, and directory3 are taking advantage of ACLs while public_heml directory is not.

The Classes

Generally, Extended-ACL defines six classes of entry, instead of well-known three class as in traditional permission system. They are:

Entry type Text Form
Owner user::rwx
Named user user:name:rwx
Owning group group::rwx
Named group group:name:rwx
Mask mask::rwx
Others other::rwx

As seen there, what is mask? Before we discuss that, let’s get deeper into new class named user and named group.

Named group and named user entries are assigned to the group class, which already contains the owning group entry. Different from the traditional permission model, the group class may now contain ACL entries with different permission sets, so the group class permissions alone are no longer sufficient to represent all the detailed permissions of all ACL entries it contains.

Well, let say that on earlier model, all group user are bound together using group permission. So one permission will be applied to all of group member. However in Extended-ACL, user is not bounded in that manner.

Therefore, the meaning of the group class permissions is redefined: under their new semantics, they represent an upper bound of the permissions that any entry in the group class will grant.

This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.

In minimal ACLs (traditional), the group class permissions are identical to the owning group permissions. In Extended-ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.

This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With Extended-ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.

Dive into Extended-ACL

On default, for every file creation a standard traditional permission model is used to “stamp” files. We can set Extended-ACL later.

Now, let’s start by cerating a directory and checking its permission. The umask determines which permissions will be masked off then the directory is created. A umask 027 disables write access for the owning group; and read,write,execute access for others.

$ umask 027
$ mkdir dir
$ ls -dl dir
drwxr-x--- ... xathrya users ... dir

The string “rwxr-x--” represents the resulting permissions for the new directory: read, write, and execute access for the owner and read and execute access for the owning group. The dots in the output of ls stand for text that is not relevant here and has been removed.

These base permissions have an equivalent representation as an ACL. ACLs are displayed using the getfacl command.

$ getfacl dir
# file: dir
# owner: xathrya
# group: users
user::rwx
group::r-x
other::---

The first three lines of output contain the file name, owner, and owning group of the file as comments. Each of the following lines contains an ACL entry for one of the three classes of users: owner, group, and other. And that is a traditional permission model.

Now we will grants read, write access to user Marina in addition to the existing permissions. For that, the -m (modify) argument of setfacl is used. The resulting ACL is again shown using the getfacl command. The -omit-header option to getfacl suppresses the three-line comment header containing the file name, owner, and owning group to shorten the examples shown.

$ setfacl -m user:marina:rw dir
$ getfacl --omit-header dir
user::rwx
user:marina:rw
group::r-x
mask::rwx
other::---

Two additional entries have been added to the ACL: one is for user Marina and the other is the mask entry. The mask entry is automatically created when needed but not provided. Its permissions are set to the union of the permissions of all entries that are in the group class, so the mask entry does not mask any permissions.

Now, to grant only read permission to Elisa, we can also do:

$ setfacl -m user:elisa:r-- dir
$ getfacl --omit-header dir
user::rwx
user:marina:rwx
user:elisa:r--
group::r-x
mask::rwx
other::---

Now, let see what these commands (one line per command) will do:

setfacl -d -m group:developer:r-x tools
setfacl -m user:root:--- supersecret.txt
setfacl -m user:marina:r-- file.txt

Now, how to remove an ACL entry from a file? There is a simple command to do so. For example, we want to lift ban from Marina on file.txt then we invoke following:

setfacl -x user:marina file.txt

Installing BIND as DNS Server on FreeBSD 8.3

December 9, 2015 | Article | No Comments

BIND by far is the most popular Domain Name System (DNS) Server used worldwide. It provides a robust and stable platform on top of which organization can build distributed computing system with the knowledge that those system are fully compliant with published DNS standards.

One of reason BIND become popular is indeed BIND is the application developed by Internet System Consortium, a nonprofit corporation dedicated to supporting the infrastructure of the universal connected self-organizing internet.

In this article we will discuss about installation and simple configuration of BIND on FreeBSD. Here I use:

  1. FreeBSD amd64 8.3

Although I use FreeBSD amd64 8.3, this method is general so we can apply it to other FreeBSD platform and version. Having a registered domain name is not necessary as for this article, but it is strongly recommended.

Installation

Make sure you have become super user by using su. Installing BIND is as easy as other ports installation.

cd /usr/ports/dns/bind99
make config
make install clean

At this point, standard installation of BIND has been successfully installed on our system. Before using BIND, we should do a little adjustment and configuration.

Add NO_BIND=YES to make.conf. This tells the make command not to build the base version of BIND if we want to rebuild FreeBSD from source. Using this method, we can prevent the system from downgrading BIND to older version.

echo 'NO_BIN=YES' >> /etc/make.conf

Next, we also want BIND to start automatically at boot time. Here we modify our rc.conf:

echo 'named_enable="YES"' >> /etc/rc.conf

Now, start the BIND if you don’t start it yet.

/etc/rc.d/named start

Resource

  1. RFC 1034 – Domain Names: Concepts and Facilities (http://tools.ietf.org/html/rfc1034)
  2. RFC 1035 – Domain Names: Implementation and Specification (http://tools.ietf.org/html/rfc1035)

IP address or Internet Protocol address plays a very important role in networking. Especially for a server. Without an IP address, our machine can’t connect to any other machine thus render our machine useless.

On earlier article, we have discussed about how to configuring network setting on FreeBSD. It covers about giving IP address for FreeBSD which connect to internet directly. But what if our server is behind a NAT (Network Address Translation) router, or in simple words: not connect internet directly. Thus we will discuss it on this article, using FreeBSD 8.3 as our example.

Let see the Scenario

FreeBSD uses a file named rc.conf to establish the system’s IP address, among other settings, during system startup. The rc.conf file contains configuration settings for the computer’s hostname, network interface cards, and which services to start at boot time. It is important that the settings in this file are correct; a typo here could hamper the system’s functionality.

A small office or home network commonly has one Internet connection that needs to be shared by multiple computers. A NAT router allows the sharing of a single Internet connection within the local (private) network. The router functions as a firewall, creating a protected zone in the private network by allowing all traffic out, but only allowing known or solicited traffic in.

The private network use a different IP, which is called Private addresses. The router has two IP addresses at two end: one public IP address which given by ISP for our home/office, and a private IP address which is used for internal used.

This scenario assume we use IPv4.

Port Forwarding

Like said before, a router can connecting two different network, one to ISP and one to our private network. Router can do this because it has a port-forward function that forwards traffic received at the router to a computer with a static IP address inside the private network. If, for example, we were hosting a web server then we would need to forward TCP port 80 (the IANA standard for HTTP) to the IP address of our FreeBSD server.

Most NAT routers that support port forwarding have built-in DHCP servers that assign computers in the private network a dynamic IP address, one that may change each time the computer logs on to the network.

DHCP works when machines simply need to connect to a network and get the first available IP address, but it’s no help to you if you want to use your FreeBSD system as a server. You’ll need a static (permanent) IP address so that information destined for your server will arrive.

Specify Static IP Address on rc.conf

Before we modify rc.conf, we need to tell the DHCP server to assign IP addresses in a range that doesn’t conflict with the server’s IP address. In other mean we choose an IP address which is not on DHCP pool address.

Router’s DHCP options should allow us to set the starting IP address. For this example, we’ll use 192.168.1.100 as the starting address for the range of addresses that can be assigned to machines, knowing that numbers are assigned from this address up (.101, .102, .103, and so on). We’ll assign 192.168.1.15 as our server’s static IP address since it is outside the range of the DHCP server.

Now let’s set this in rc.conf. Edit /etc/rc.conf and you should see something like the following in your rc.conf file. Your FQDN should be here if specified during setup; the interface em0 may be different.

hostname="veda.celestial-being.net"
ifconfig_em0="DHCP"

Note: If you don’t already have the hostname set, be sure to set it correctly. The hostname should be your system’s fully qualified domain name; veda is the name of the machine and celestial-being.net is your registered domain name.

Insert router’s IP address in the defaultrouter statement as shown below. Using our example scenario above, the hostname, ifconfig, and defaultrouter statements should now look like this:

hostname="veda.celestial-being.net"
ifconfig_em0="inet 192.168.1.15 netmask 255.255.255.0"
defaultrouter="192.168.1.1"

Notice that we have replaced “DHCP” with our static IP address and added the netmask address (255.255.255.0 is the default netmask address in most configurations).

We’ve also added a defaultrouter line which points to the NAT router’s IP address. This address, 192.168.1.1, will be the IP address you enter into your web browser to access the router web configuration; this is also called the default gateway.

Now save and exit.

Using Dynamic DNS

Dynamic DNS is a service provided by third-party companies that keeps track of a computer’s public IP address. These providers automatically update our domain name’s associated IP address if it changes for any reason. Most Internet service providers use DHCP servers to assign public IP addresses to their customers dynamically. Unless you pay for a static IP address, this dynamically assigned address may change from time to time.

When we register our domain name, we can specify the target IP address of our server if we wish to host our own services. Many people mistakenly assume that their current, dynamic IP address will be theirs indefinitely. When our dynamic IP address changes (which may happen frequently or once every few months), our server appear to “drop off ” the Internet since our domain registrar’s records point to the previous IP address, which is no longer valid. We then have to go back to domain registrar and notify them of our new IP address to regain our Internet presence (this is usually accomplished through a web-based control panel).

This is where dynamic DNS service providers become useful. These third-party companies allow you to keep our IP address updated by using a client program on your server to detect when the IP changes. When it does, the client program automatically contacts the dynamic DNS service to update your DNS record so you stay “live”. When using these services you need to point your domain registrar to your dynamic DNS service’s servers, which then point to your updated IP address. Most dynamic DNS providers charge a fee for their services, though there are a few free ones, like ZoneEdit (http://zoneedit.com). By combining a dynamic DNS service provider with a dynamic DNS updating client like ddclient, we can provide a static IP-like Internet presence.

Installing OpenVPN on FreeBSD 8.3

December 5, 2015 | Article | No Comments

OpenVPN is one of open source implementation of Virtual Private Network available.

In this article we will discuss about how to install OpenVPN on FreeBSD 8.3.

Installation

Installing OpenVPN is as easy as installing any FreeBSD ports.

cd /usr/ports/security/openvpn
make install clean

Once installed, OpenVPN will store its ocnfigurations on /usr/local/share/doc/openvpn.

Make a directory /usr/local/etc/openvpn and copy all configuration files from /usr/local/share/doc/openvpn to this new directory.

mkdir /usr/local/etc/openvpn
cp /usr/local/share/doc/openvpn/sample-config/files/server.conf /usr/local/etc/openvpn
cp -a /usr/local/share/doc/openvpn/easy-rsa /usr/local/etc/openvpn

Creating RSA Key

OpenVPN is a tunneling network. Our connection made to OpenVPN through encrypted channel. Therefore, to enable OpenVPN we should create keys. In this section we will discuss about how to do it.

A good news is, we don’t have to create the key from scratch. OpenVPN has made a script to automatically create it for us. Now invoke following to do preparation:

chmod 0755 /usr/local/etc/openvpn/easy-rsa/2.0/*
cd /usr/local/etc/openvpn/easy-rsa/2.0
sh
echo 'export KEY_COUNTRY="ID"' >> vars
echo 'export KEY_PROVINCE="JB"' >> vars
echo 'export KEY_CITY="BANDUNG"' >> vars
echo 'export KEY_ORG="Celestial Being"' >> vars
echo 'export KEY_EMAIL="[email protected]"' >> vars

Now we create the certificate ca.crt

. ./vars
./clean-all
./build-ca

And then build the server.key

./build-key-server server

Next the client.key

./build-key client

Build DH parameters with 2014 bit long

./build-dh

Copy the Keys to a special purposed directory for storing keys.

mkdir /usr/local/etc/openvpn/keys
cp /usr/local/etc/openvpn/easy-rsa/2.0/keys/* /usr/local/etc/openvpn/keys
./clean-all

Configuring Server

After creating the keys, we will proceed to configuring the OpenVPN server. The file we must edit is /usr/local/etc/openvpn/server.conf. Here is sample configuration we can applied to our server:

port 1194
proto udp
dev tap
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key # This file should be kept secret
dh /usr/local/etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log

Autostart on Boot

To run OpenVPN automatically at boot time, we can edit /etc/rc.conf write following:

gateway_enable="YES"
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"
openvpn_if="tap"

Enabling IP Forwarding

IP Forwarding is needed to forward IP packet which received by servers to corresponding client inside VPN.

sysctl net.inet.ip.forwarding=1

Starting OpenVPN Server

Last part, we should start the OpenVPN by:

/usr/local/etc/rc.d/openvpn start

And that’s it. You now have OpenVPN on your network

Social media & sharing icons powered by UltimatelySocial