The certificate for will expire in x days

O servidor estava a enviar este email:

################# SSL Certificate Warning ################

Certificate for hostname '', in file (or by nickname):

The certificate needs to be renewed; this can be done
 using the 'genkey' program.

Browsers will not be able to correctly connect to this
 web site using SSL until the certificate is renewed.

 Generated by certwatch(1)

You can use the ‘genkey’ program to renew an SSL certificate if your certificate is signed by a CA (Certificate Authority), but if you’re using a self-signed certificate (like me), then genkey won’t work. The quickest solution is to merely re-create your own certificate.

Step 1: Verify Your Current Certificate Directives

If your certificate has recently expired, then it’s probably been at least a year since you tinkered with it. The warning email told you the path of your certificate file, but you should also verify the filenames, locations, and the directives of your web server’s SSL configuration by doing:

grep SSLCertificate /etc/httpd/conf.d/ssl.conf

You should get something like:

# Point SSLCertificateFile at a PEM encoded certificate. If
 SSLCertificateFile /etc/pki/tls/certs/server.crt
 SSLCertificateKeyFile /etc/pki/tls/private/server.key
 # Point SSLCertificateChainFile at a file containing the
 # the referenced file can be the same as SSLCertificateFile
 #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

You’re interested in the SSLCertificateFile and SSLCertificateKeyFile directives. This example uses server.crt and server.key as the names of the certificate files. Yours may be different. Just replace them as necessary in the following instructions.

Next, take note of the permissions of those two files:

ls -lh /etc/pki/tls/certs/server.crt
 -rw------- 1 root root 1.5K Jun 24 23:02 /etc/pki/tls/certs/server.crt

ls -lh /etc/pki/tls/private/server.key
 -rw------- 1 root root 891 Jun 24 23:02 /etc/pki/tls/private/server.key

They are owned by root and can only be read and written to by root (permission 600). Your new files will need the same permissions when you’re done.

Step 2: Create the New Self-Signed Certificate and Key Files

Type the following:

openssl req -new -days 365 -x509 -nodes -newkey rsa:2048 -out /etc/pki/tls/certs/server.crt -keyout /etc/pki/tls/private/server.key

Answer the questions as they are presented to create your new certificate files, starting with the two-letter country code and ending with your email address. If you make a mistake, don’t worry. Just re-run the command and it will overwrite the files.

Your file permissions may not have been affected, but in some cases you’ll need to update their permissions. Do:

chmod 600 /etc/pki/tls/certs/server.crt
chmod 600 /etc/pki/tls/private/server.key

Step 3: Restart Your Web Server

Type service httpd restart to restart your web server and tell it to use the new certificate files.

You’re done!



Linux: Alterar home de user

To alter an existing user’s home directory. usermod is the command to edit an existing user. -d (abbreviation for –home) will change the user’s home directory. Adding -m (abbreviation for –move-home will also move the content from the user’s current directory to the new directory.

usermod -m -d /newhome/username username

Instalar certificado SSL no Apache

Converter chaves:

Mais do que um certificado por domínio:

Configure Munin to graph MySQL on CentOS 5/6

If you’re running a CentOS 5/6 Server and installed Munin to graph the system stats, you’ll mostly likely notice that the generated graphs do not include MySQL.

Unfortunately, by default, Munin tries to read MySQL data using the root account and no password and fails.

But there’s an easy way to fix this:

Enter your MySQL Database Server administration interface and create a new user munin with a safe password (remember it, you’ll need it later), set it to only log in from localhost and add the Superuser permission.

Then navigate to Database Permissions and add the previously created munin user on database mysql, again only for localhost and only grant the Select table data permission.

Moving on, open the /etc/munin/plugin-conf.d/munin-node file in your favourite editor and add (or edit if already exists):

env.mysqladmin /usr/bin/mysqladmin
env.mysqluser munin
env.mysqlpassword your-previously-defined-password

If you’re using innodb tables, you will need to create the /etc/munin/plugin-conf.d/mysql_innodb file and this in it to ignore error about it (which Munin will most likely generate):

env.warning 0
env.critical 0

Now it’s time to test if the plugin works. Run in the console:

munin-node-configure --suggest | grep mysql

You should get something like

mysql_                     | yes  | yes (+bin_relay_log +commands +connections +files_tables +innodb_bpool +innodb_bpool_act +innodb_insert_buf +innodb_io +innodb_io_pend +innodb_log +innodb_rows +innodb_semaphores +innodb_tnx +myisam_indexes +network_traffic +qcache +qcache_mem +replication +select_types +slow +sorts +table_locks +tmp_tables)

If you’re missing any required Perl modules, you’ll see a | no | no and the needed modules’ names.

mysql_                     | no   | no [Missing dependency Cache::Cache]

Install them and then try again.

yum install perl-Cache-Cache perl-IPC-ShareLite

If all is well, it’s time to activate the plugin by running

ln -s /usr/share/munin/plugins/mysql_* /etc/munin/plugins

and then restart munin-node

service munin-node restart

Then just wait 10-20 minutes for your graphs to show up.

Fail2ban unban IP

Since 0.8.8 there is the unbanip option. It can be triggered by the set command.

fail2ban-client set ssh-iptables unbanip m.y.i.p

more generic:

fail2ban-client set :jail unbanip :ip


Instalar plugin Java no Firefox (CentOS)

Java must be installed on the system first. This procedure only works with the version you download from Oracle; it will not work with the OpenJDK version of Java you’ll have when using the ‘yum install java’ command.

Download Linux x64 RPM from Oracle’s Java Downloads for All Operating Systems page.

Close Firefox.

Change to root user and enter password.


Change directory to /usr/java. If it isn’t created, create it.

mkdir /usr/java
cd /usr/java

Execute rpm on the Java RPM you just downloaded…

rpm -ivh /home/basejump/Downloads/jre-7u21-linux-x64.rpm

Validate with:

java -version

Delete the original RPM; you don’t need that anymore.

rm -rf /home/basejump/Downloads/jre-8u60-linux-x64.rpm

From the /usr/java directory, Find the Firefox plugin (which gets installed with java):

find . | grep libnpjp

For me, that returned:


Change to directory for Firefox plugins:

cd /usr/lib64/mozilla/plugins

Be careful. There is also a /usr/lib/mozilla/plugins directory. Be sure you’re in lib64!

Create symbolic link to the plugin:

ln -fs /usr/java/jre1.8.0_60/lib/amd64/

Start Firefox and validate by going to Tools > Addons > Plugins. You should now see Java Plug-in 1.x.x enabled.


Check all files on the computer, but only display infected files:

clamscan -r -i /home/eb23marrazes/public_html/

Check files in the USER home directory and remove infected files (WARNING: Files are gone.):

clamscan -r --remove /home/eb23marrazes/public_html/

VSFTPD: desativar dns reverse lookups

Tenho um servidor de FTP a correr (vsftpd) que está configurado para banir IPs que falhem o login 5 vezes seguidas. Funciona tudo corretamente excepto nas situações em que o reverse de um IP aponta para um endereço inválido. Basicamente o PAM faz o lookup, regista em /var/log/secure e o fail2ban lê o ficheiro para bloquear. Como o fail2ban não consegue resolver esses nomes, então isto permitia que alguns IPs tentasse aceder indefinidamente ao servidor e nunca fossem bloqueados!

Solução… alterar a configuração do vsftpd para não fazer o reverse lookup.

Informação relevante aqui: vsftpd bug fix


the DNS reverse lookup feature was implemented without any way to disable
it. This update contains the parameter 'reverse_lookup_enable', which
allows users to enable or disable the DNS reverse lookup functionality.


Upgrade to CentOS 6.5 from CentOS 6.x

1. Change to root User

su -
## OR ##
sudo -i


2. Backup all important data

  • Backup /etc diretory
  • Backup important logs /var/log
  • Backup web server configs and sites
  • Dump MySQL databases
  • Dump PostgreSQL databases
  • Backup all what you need if something goes wrong


3. Check list of packages that are going to be updated

yum list updates


4. Upgrade with yum update

Official way to do upgrade:

yum update

Another way to do update is first clean all, second update glibc, yum, rpm and python packages and then update other packages like following:

yum clean all
yum update glibc* yum* rpm* python*
yum update


5. Reboot



6. Check CentOS 6.5 (Final) release info and Check your entire system

cat /etc/redhat-release
## Output ##
CentOS release 6.5 (Final)

Following needs redhat-lsb package

lsb_release -a
## Output ##
LSB Version:    :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.5 (Final)
Release:        6.5
Codename:       Final

Check that your system is working normally and test every services.



Comandos linux

Ligações activas

netstat -ant

Contar nº de ligações na porta 80

netstat -ant | grep ":80" | wc -l

Contar nº de ligações na porta 3306

netstat -ant | grep ":3306" | wc -l

Verificar a natureza das ligações activas

netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n

Indica o nº de tipo de ligações activas

netstat -ant | grep 80 | awk '{print $6}' | sort | uniq -c | sort -n