Posts Tagged ‘automated’

Install certbot on Debian, Ubuntu, CentOS, Fedora Linux 10 / Generate and use Apache / Nginx SSL Letsencrypt certificates

Monday, December 21st, 2020

letsencrypt certbot install on any linux distribution with apache or nginx webserver howto</a><p> Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit <a data-cke-saved-href=
Internet Security Research Group (ISRG). ISRG group gave initiative with the goal to "encrypt the internet", i.e. offer free alternative to the overpriced domani registrer sold certificates with the goal to make more people offer SSL / TSL Free secured connection line on their websites. 
ISRG group supported Letsencrypt non-profit certificate authority actrively by Internet industry standard giants such as Mozilla, Cisco, EFF (Electronic Frontier Foundation),  Facebook, Google Chrome, Amazon AWS, OVH Cloud, Redhat, VMWare, Github and many many of the leading companies in IT.

Letsencrpyt is aimed at automating the process designed to overcome manual creation, validation, signing, installation, and renewal of certificates for secure websites. I.e. you don't have to manually write on console complicated openssl command lines with passing on Certificate CSR /  KEY / PEM files etc and generate Self-Signed Untrusted Authority Certificates (noted in my previous article How to generate Self-Signed SSL Certificates with openssl or use similar process to pay money generate secret key and submit the key to third party authority through a their website webadmin  interface in order to Generate SSL brought by Godaddy or Other Certificate Authority.

But of course as you can guess there are downsides as you submit your private key automatically via letsencrypt set of SSL certificate automation domain scripts to a third party Certificate Authority which is at Letsencrypt.org. A security intrusion in their private key store servers might mean a catastrophy for your data as malicious stealer might be able to decrypt your data with some additional effort and see in plain text what is talking to your Apache / Nginx or Mail Server nevertheless the cert. Hence for a high standards such as PCI environments Letsencrypt as well as for the paranoid security freak admins,  who don't trust the mainstream letsencrypt is definitely not a choice. Anyways for most small and midsized businesses who doesn't hold too much of a top secret data and want a moderate level of security Letsencrypt is a great opportunity to try. But enough talk, lets get down to business.

How to install and use certbot on Debian GNU / Linux 10 Buster?
Certbot is not available from the Debian software repositories by default, but it’s possible to configure the buster-backports repository in your /etc/apt/sources.list file to allow you to install a backport of the Certbot software with APT tool.
 

1. Install certbot on Debian / Ubuntu Linux

 

root@webserver:/etc/apt# tail -n 1 /etc/apt/sources.list
deb http://ftp.debian.org/debian buster-backports main


If not there append the repositories to file:

 

  • Install certbot-nginx certbot-apache deb packages

root@webserver:/ # echo 'deb http://ftp.debian.org/debian buster-backports main' >> /etc/apt/sources.list

 

  • Install certbot-nginx certbot-apache deb packages

root@webserver:/ # apt update
root@webserver:/ # apt install certbot python-certbot-nginx python3-certbot-apache python-certbot-nginx-doc


This will install the /usr/bin/certbot python executable script which is used to register / renew / revoke / delete your domains certificates.
 

2. Install letsencrypt certbot client on CentOS / RHEL / Fedora and other Linux Distributions

 


For RPM based distributions and other Linux distributions you will have to install snap package (if not already installed) and use snap command :

 

 

[root@centos ~ :] # yum install snapd
systemctl enable –now snapd.socket

To enable classic snap support, enter the following to create a symbolic link between

[root@centos ~ :] # ln -s /var/lib/snapd/snap /snap

snap command lets you install, configure, refresh and remove snaps.  Snaps are packages that work across many different Linux distributions, enabling secure delivery and operation of the latest apps and utilities.

[root@centos ~ :] # snap install core; sudo snap refresh core

Logout from console or Xsession to make the snap update its $PATH definitions.

Then use snap universal distro certbot classic package

 [root@centos ~ :] # snap install –classic certbot
[root@centos ~ :] # ln -s /snap/bin/certbot /usr/bin/certbot
 

 

If you're having an XOrg server access on the RHEL / CentOS via Xming or other type of Xemulator you might check out also the snap-store as it contains a multitude of packages installable which are not usually available in RPM distros.

 [root@centos ~ :] # snap install snap-store


how-to-install-snap-applications-on-centos-rhel-linux-snap-store

snap-store is a powerful and via it you can install many non easily installable stuff on Linux such as eclipse famous development IDE, notepad++ , Discord, the so favourite for the Quality Assurance guy Protocol tester Postman etc.

  • Installing certbot to any distribution via acme.sh script

Another often preferred solution to Universally deploy  and upgrade an existing LetsEncrypt program to any Linux distribution (e.g. RHEL / CentOS / Fedora etc.) is the acme.sh script. To install acme you have to clone the repository and run the script with –install

P.S. If you don't have git installed yet do

root@webserver:/ # apt-get install –yes git


and then the usual git clone to fetch it at your side

# cd /root
# git clone https://github.com/acmesh-official/acme.sh
Cloning into 'acme.sh'…
remote: Enumerating objects: 71, done.
remote: Counting objects: 100% (71/71), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 12475 (delta 39), reused 38 (delta 18), pack-reused 12404
Receiving objects: 100% (12475/12475), 4.79 MiB | 6.66 MiB/s, done.
Resolving deltas: 100% (7444/7444), done.

# sh acme.sh –install


To later upgrade acme.sh to latest you can do

# sh acme.sh –upgrade


In order to renew a concrete existing letsencrypt certificiate

# sh acme.sh –renew domainname.com


To renew all certificates using acme.sh script

# ./acme.sh –renew-all

 

3. Generate Apache or NGINX Free SSL / TLS Certificate with certbot tool

Now lets generate a certificate for a domain running on Apache Webserver with a Website WebRoot directory /home/phpdev/public/www

 

root@webserver:/ # certbot –apache –webroot -w /home/phpdev/public/www/ -d your-domain-name.com -d your-domain-name.com

root@webserver:/ # certbot certonly –webroot -w /home/phpdev/public/www/ -d your-domain-name.com -d other-domain-name.com


As you see all the domains for which you will need to generate are passed on with -d option.

Once certificates are properly generated you can test it in a browser and once you're sure they work as expected usually you can sleep safe for the next 3 months ( 90 days) which is the default for TSL / SSL Letsencrypt certificates the reason behind of course is security.

 

4. Enable freshly generated letsencrypt SSL certificate in Nginx VirtualHost config

Go to your nginx VirtualHost configuration (i.e. /etc/nginx/sites-enabled/phpmyadmin.adzone.pro ) and inside chunk of config add after location { … } – 443 TCP Port SSL listener (as in shown in bolded configuration)
 

server {

….
   location ~ \.php$ {
      include /etc/nginx/fastcgi_params;
##      fastcgi_pass 127.0.0.1:9000;
      fastcgi_pass unix:/run/php/php7.3-fpm.sock;
      fastcgi_index index.php;
      fastcgi_param SCRIPT_FILENAME /usr/share/phpmyadmin$fastcgi_script_name;
   }
 

 

 

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/phpmyadmin.adzone.pro/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/phpmyadmin.adzone.pro/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

 

5. Enable new generated letsencrypt SSL certificate in Apache VirtualHost


In /etc/apache2/{sites-available,sites-enabled}/your-domain.com-ssl.conf you should have as a minimum a configuration setup like below:
 

 

NameVirtualHost *:443 <VirtualHost 123.123.123.12:443>
    ServerAdmin hipo@domain.com
    ServerName www.pc-freak.net
    ServerAlias www.your-domain.com wwww.your-domain.com your-domain.com
 
    HostnameLookups off
    DocumentRoot /var/www
    DirectoryIndex index.html index.htm index.php index.html.var

 

 

CheckSpelling on
SSLEngine on

    <Directory />
        Options FollowSymLinks
        AllowOverride All
        ##Order allow,deny
        ##allow from all
        Require all granted
    </Directory>
    <Directory /var/www>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
##      Order allow,deny
##      allow from all
Require all granted
    </Directory>

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/your-domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/your-domain.com/privkey.pem
</VirtualHost>

 

6. Simulate a certificate regenerate with –dry-run

Soon before the 90 days period expiry approaches, it is a good idea to test how all installed Nginx webserver certficiates will be renewed and whether any issues are expected this can be done with the –dry-run option.

root@webserver:/ # certbot renew –dry-run

 

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/adzone.pro/fullchain.pem (success)
  /etc/letsencrypt/live/cdn.natsr.pro/fullchain.pem (success)
  /etc/letsencrypt/live/mail.adzone.pro/fullchain.pem (success)
  /etc/letsencrypt/live/natsr.pro-0001/fullchain.pem (success)
  /etc/letsencrypt/live/natsr.pro/fullchain.pem (success)
  /etc/letsencrypt/live/phpmyadmin.adzone.pro/fullchain.pem (success)
  /etc/letsencrypt/live/www.adzone.pro/fullchain.pem (success)
  /etc/letsencrypt/live/www.natsr.pro/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

 

7. Renew a certificate from a multiple installed certificate list

In some time when you need to renew letsencrypt domain certificates you can list them and choose manually which one you want to renew.

root@webserver:/ # certbot –force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate and install certificates?
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: Apache Web Server plugin (apache)
2: Nginx Web Server plugin (nginx)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: adzone.pro
2: mail.adzone.pro
3: phpmyadmin.adzone.pro
4: www.adzone.pro
5: natsr.pro
6: cdn.natsr.pro
7: www.natsr.pro
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 3
Renewing an existing certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/phpmyadmin.adzone.pro

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: No redirect – Make no further changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/phpmyadmin.adzone.pro

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Your existing certificate has been successfully renewed, and the new certificate
has been installed.

The new certificate covers the following domains: https://phpmyadmin.adzone.pro

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=phpmyadmin.adzone.pro
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

IMPORTANT NOTES:
 – Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/phpmyadmin.adzone.pro/fullchain.pem

   Your key file has been saved at:
   /etc/letsencrypt/live/phpmyadmin.adzone.pro/privkey.pem
   Your cert will expire on 2021-03-21. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 – If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

 

8. Renew all present SSL certificates

root@webserver:/ # certbot renew

Processing /etc/letsencrypt/renewal/www.natsr.pro.conf
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Cert not yet due for renewal

 

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/adzone.pro/fullchain.pem expires on 2021-03-01 (skipped)
  /etc/letsencrypt/live/cdn.natsr.pro/fullchain.pem expires on 2021-02-28 (skipped)
  /etc/letsencrypt/live/mail.adzone.pro/fullchain.pem expires on 2021-02-28 (skipped)
  /etc/letsencrypt/live/natsr.pro-0001/fullchain.pem expires on 2021-03-01 (skipped)
  /etc/letsencrypt/live/natsr.pro/fullchain.pem expires on 2021-02-25 (skipped)
  /etc/letsencrypt/live/phpmyadmin.adzone.pro/fullchain.pem expires on 2021-03-21 (skipped)
  /etc/letsencrypt/live/www.adzone.pro/fullchain.pem expires on 2021-02-28 (skipped)
  /etc/letsencrypt/live/www.natsr.pro/fullchain.pem expires on 2021-03-01 (skipped)
No renewals were attempted.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

 

 

9. Renew all existing server certificates from a cron job


The certbot package will install a script under /etc/cron.d/certbot to be run that will attempt every 12 hours however from my experience
often this script is not going to work, the script looks similar to below:

# Upgrade all existing SSL certbot machine certificates

 

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

Another approach to renew all installed certificates if you want to have a specific options and keep log of what happened is using a tiny shell script like this:

 

10. Auto renew installed SSL / TSL Certbot certificates with a bash loop over all present certificates

#!/bin/sh
# update SSL certificates
# prints from 1 to 104 (according to each certbot generated certificate and triggers rewew and logs what happened to log file
# an ugly hack for certbot certificate renew
for i in $(seq 1 104); do echo "Updating $i SSL Cert" | tee -a /root/certificate-update.log; yes "$i" | certbot –force-renewal | tee -a /root/certificate-update.log 2>&1; sleep 5; done

Note: The seq 1 104 is the range depends on the count of installed SSL certificates you have installed on the machine, that can be seen and set the proper value according to your case when you run one time certbot –force-renewal.
 

Changing ’33 days has gone without being checked’ automated fsck filesystem check on Debian Linux Desktops – Reduce FS check waiting on Linux notebooks

Saturday, November 17th, 2012

Increasing default setting of automatic disk scheck on Debian Linux to get rid of annoying fsck waiting on boot / Less boot waiting by disabling automated fsck root FS checks

The periodic scheduled file system check that is set as a default behavior in Debian GNU / Linux is something very wise in terms of data security. However in terms of Desktop usability (especially for highly mobile users wtih notebooks like me) it's very inconvenient.

If you're a Linux laptop user with Debian GNU / Linux or other Linux distro, you certainly many times have experienced the long waiting on boot because of the routine scheduled fsck check:

/dev/sda5 has gone 33 days without being checked, check forced
/dev/sda5 |====== .....

In this little article, I will explain how to change the 33 mount times automated fsck filesystem  check on Debian GNU / Linux to avoid frequent fsck waitings. As long as I know this behaviour is better tailored on Ubuntu as Ubuntu developers, make Ubuntu to be targeting users and they have realized the 33 mounts auto check is quite low for 'em.

1. Getting information about current file system partitions with fdisk and mount

a) First it is good practice to check out all present system mountable ex3 / reiserfs file systems, just to give you an idea what you're doing:

noah:~#  fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2d92834c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         721     5786624   27  Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2   *         721        9839    73237024    7  HPFS/NTFS
/dev/sda3            9839       19457    77263200    5  Extended
/dev/sda5            9839       12474    21167968+  83  Linux
/dev/sda6           12474       16407    31593208+  83  Linux
/dev/sda7           16407       16650     1950448+  82  Linux swap / Solaris
/dev/sda8           16650       19457    22551448+  83  Linux

 

Second, find out which one is your primary root filesystem, and  whether the system is partitioned to have /usr , /var and /home in separate partitions or not.

b) finding the root directory mount point ( / ):

noah:~ # mount |head -n 1
/dev/sda8 on / type ext3 (rw,errors=remount-ro)

c) looking up if /usr /var and /home in separate partitions exist or all is on the / partition

noah:~# mount |grep -i -E '/usr|/var/|/home'
/dev/sda5 on /home type ext3 (rw,errors=remount-ro)

2. Getting information about Linux mounted partitions filesystem parameters ( tune2fs )
 

noah:~# /sbin/tune2fs -l /dev/sda8

tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          8e0901b1-d569-45b2-902d-e159b104e330
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1411680
Block count:              5637862
Reserved block count:     281893
Free blocks:              578570
Free inodes:              700567
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Filesystem created:       Sun Jun 22 16:47:48 2008
Last mount time:          Thu Nov 15 14:13:10 2012
Last write time:          Tue Nov 13 13:39:56 2012
Mount count:              6
Maximum mount count:      33
Last checked:             Tue Nov 13 13:39:56 2012
Check interval:           15552000 (6 months)
Next check after:         Sun May 12 14:39:56 2013
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Journal inode:            8
First orphan inode:       595996
Default directory hash:   tea
Directory Hash Seed:      2f96db3d-9134-492b-a361-a873a0c8c3c4
Journal backup:           inode blocks

 

noah:~# /sbin/tune2fs /dev/sda5

tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          26aa6017-e675-4029-af28-7d346a7b6b00
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1324512
Block count:              5291992
Reserved block count:     264599
Free blocks:              412853
Free inodes:              1247498
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Filesystem created:       Thu Jul 15 18:46:03 2010
Last mount time:          Thu Nov 15 14:13:12 2012
Last write time:          Thu Nov 15 14:13:12 2012
Mount count:              12
Maximum mount count:      27
Last checked:             Sat Nov 10 22:43:33 2012
Check interval:           15552000 (6 months)
Next check after:         Thu May  9 23:43:33 2013
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1032306
Default directory hash:   half_md4
Directory Hash Seed:      8ef0fe5a-43e3-42bf-a1b9-ae6e1606ecd4
Journal backup:           inode blocks
 

As you see from above paste from my notebook, there is a plenty of options you can tweak in a filesystem.. However as the aim of my article is not to be a FS tweaking guide I will stick only to the important for me  which is Mount Count:

noah:~#  tune2fs -l /dev/sda5|grep -i -E 'mount count|Last checked'
Mount count:              12
Maximum mount count:      27
Last checked:             Sat Nov 10 22:43:33 2012

As you see 'Mount Count: 12', indicates there are 12 mounts of filesystem /dev/sda5 since the last time it was fsck-ed.
'Maximum mount count: 27' set for this filesystem indicates that after 27 times mount is done more than 27 times, a fsck check has to be issued. In other words after 27 mounts or re-mounts of /dev/sda5 which mostly occur after system reboot on system boot time.

Restarting system is not a common on servers but with the increased number of mobile devices like notebooks Android tablets whatever 27 restarts until fsck is too low. On the other hand filesystem check every now and then is a necessity as mobility increases the possibility for a physical damage of the Hard Disk Drive.

Thus my person view is increasing 'Maximum mount count:' 27 to 80 is much better for people who move a lot and restart laptop at least few times a day. Increasing to 80 or 100 times, means you will not have to wait for a file system fsck every week (6, 7 days),. for about at 8-10 minutes (whether on newer hard disks notebooks with 500 GB space and more), it might even take 15 – 20 minutes.
I switch on and off my computer 2 to 3 times a day, because I move from location to location. Whether maximum mount count is 80, this means a FSCK will be ensued every 40/2 = 40 days or so which is quite a normal timing for a Scheduled filesystem integrity check.

noah:~# tune2fs -c 80 -i 80 /dev/sda8
tune2fs 1.41.12 (17-May-2010)
Setting maximal mount count to 80
Setting interval between checks to 6912000 seconds
 

-c argument sets (-c max-mount-counts)

-i sets interval betweenchecks (-i  interval-between-checks[d|m|w] - days, months, weeks)

You can consequentially, check approximately, when the next ext3 FS check will happen with:

noah:~# tune2fs -l /dev/sda8 |grep -i 'check'
Last checked:             Tue Nov 13 13:39:56 2012
Check interval:           6912000 (2 months, 2 weeks, 6 days)
Next check after:         Fri Feb  1 13:39:56 2013
 

For people, who want to completely disable periodic Linux FSCK chcks and already use some kind of Backup automated solution (Dropbox, Ubuntu One …), that makes a backup copy of their data on a Cluster / Cloud – as Clusters are fuzzy called nowadays):

noah:~# tune2fs -c 0 -i 0 /dev/sda8
tune2fs 1.41.12 (17-May-2010)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds

Again if you don't do a regular backup of your filesystem NEVER EVER do this BEWARE !

To be 100% sure, /dev/sda8 periodic filesystem will not happen again issue:

tune2fs -l /dev/sda8 |grep -i -E 'mount|check'
Last mounted on:          <not available>
Default mount options:    (none)
Last mount time:          Thu Nov 15 14:13:10 2012
Mount count:              6
Maximum mount count:      -1
Last checked:             Tue Nov 13 13:39:56 2012
Check interval:           0 (<none>)
 

By the way it is intestesting to mention Mount Count and Maximum Mount Count FS variables are set during initial creation of the filesystem with mkfs.ext3, in Debian and derivative distros this is done by the Debian Installer program. On Fedora and CentOS and most of other RPM based distros except SuSE by Anaconda Installer prog.

As of time of writing this article, for custom created filesystems with mkfs.ext3 Maximum mount count is     27.

BTW on CentOS, developers has by default set the Maximum mount count to beset to infinitive value:

/sbin/tune2fs -l /dev/sda1|grep -i 'mount count'
Mount count:              39

Maximum mount count:      -1
The same 'deskop wise' behavior of Maximum mount count: -1 is set by default also on Fedora and RHEL. Meaning RPM distro users are free of this annoyance.

3. Remove fsck filesystem check on boot in /etc/fstab
 

Usually Desktop and laptop Linux users, would not need do that but it is a good information to know.

/etc/fstab by default sets  the filesystems to be checked for bad blocks in case  if the system was shutdown due to electricity failure or hang-up, left without proper un-mounting. Though, sometimes this is very helpful as it fixes improperly complete writing on the HDD, those who administrate servers knows how annoying it is to be asked for a root password input on the physical console, whether the system fails to boot waiting for password input.
In remotely administrated servers it makes things even worser as you have to bother a tech support guy to go to the system and input the root password and type fsck /dev/whatever command manually. With notebooks and other Desktops like my case it is not such a problem to just enter root password but it still takes time. Thus it is much better to just make this fsck test filesystem on errors to be automatically invoked on filesystem errors.

A standard default records in /etc/fstab concerning root filesystem and others is best to be something like this:

/dev/sda8       /               ext3    errors=remount-ro 0       1
UUID=26aa6017-e675-4029-af28-7d346a7b6b00       /home           ext3    errors=remount-ro 0     1

The 1's in the end of each line instruct filesystems to be automatically checked with no need for user interaction in case of FS mount errors.

Some might want to completely disable, remount read only and drop into single user mode though this is usually not a good idea, to do so:

/dev/sda8       /               ext3    errors=remount-ro 0       0
UUID=26aa6017-e675-4029-af28-7d346a7b6b00       /home           ext3    errors=remount-ro 0     0

 

4. Forcing check on next reboot in case you suspect (bad blocks) or inode problems with filesystem

If you're on Linux hosts which for some reason you have disabled routine fsck it is useful to know about the existence of:

 /forcefcsk file

Scheduling a reboot nomatter, what settings you have for FS can be achieved by simply creating forcefsck in / i.e.:

noah:~# touch /forcefsck

 

5. Force the server to not fsck on next reboot

noah:~# /sbin/shutdown -rf now

The -f flag  tells to skip the fsck for all file systems defined in /etc/fstab during the next reboot.Unlike using tune2fs to set permanent reboot behavior it only takes effect during next boot.