bootrec /fixmbr bootrec /fixboot bootrec /scanos bootrec /rebuildbcd
bootrec /fixmbr bootrec /fixboot bootrec /scanos bootrec /rebuildbcd
GnuPG (GNU Privacy Guard) is a tool for encrypting and signing data. It is a completely free implementation of the OpenPGP standard (defined by RFC4880), which is also known as GPG. I myself prefer the command line over any GUI for GnuPG, because it is typically faster to execute stuff without having to move the mouse. This post contains a brief overview of the most important commands you probably have to use when working with GnuPG.
$ gpg --gen-key
You will be asked what kind of key you want, simply proceed with the instructions that are given to you.
Listing public keys:
$ gpg --list-keys
Listing private keys:
$ gpg --list-secret-keys
To export a public key into a file called
$ gpg --export -a "User Name" > public.asc
To export a private key into a file called
$ gpg --export-secret-key -a "User Name" > private.asc
Back ’em up!
To import a public key from a file called
$ gpg --import public.asc
To import a private key from a file called
$ gpg --allow-secret-key-import --import private.asc
Once you have imported the person’s public key, you must now set the trust level of the key. This also prevents GPG from warning you every time you encrypt something with the recently imported public key.
Respectively specify the other person’s name or email in the command and proceed with the instructions that are given to you:
$ gpg --edit-key joe
To delete a public key:
$ gpg --delete-key "Real Name"
To delete private key:
$ gpg --delete-secret-key "Real Name"
$ gpg --fingerprint
To encrypt a file named file.txt for a single individual, specify that individual as a recipient.
$ gpg --encrypt --recipient joe file.txt
The encrypted file is going to have the
.gpg extension. In this case
file.txt.gpg will be created after executing the command, which you can send to the receiver.
To encrypt a file so that only you yourself can decrypt it, then specify yourself as the recipient.
$ gpg --encrypt --recipient 'My Name' file.txt
To encrypt a file so that both you and the other person can decrypt the file, specify both you and the other person as recipients.
$ gpg --encrypt --recipient joe --recipient 'My Name' file.txt
To encrypt a file for a group of individuals, define the group in your GPG configuration file (see below), and then specify the group as a recipient.
$ gpg --encrypt --recipient journalists filename.txt
There’s a shorter version to accomplish the things we have done above:
$ gpg -e -r journalists file.txt
$ gpg --decrypt file.txt.gpg
A new decrypted file without the
.gpg extension will be created, in this case
file.txt. Additionally omit
--decrypt if you are working with a binary.
You can summarize individuals to single groups by editing your GPG configuration (e.g. in
~/.gnupg/gpg.conf). To get back to the example above, we create a group called
journalists containing several individuals:
group journalists = joe tom donald
Add this line to your GPG configuration file.
One way to transmit mail within a local server is by sending them directly through third party mail servers on the Internet using the SMTP protocol.
Postfix is a free and open-source mail transfer agent (MTA) and available in most Linux distributions (including CentOS 7!).
This guide will outline the basic steps on how to setup Postfix to use your mail-service-provider’s SMTP server for outgoing mail. Once configured, all mails from your server will be sent through it.
The following configuration will use 1und1’s mail server as an example.
Install the required packages:
$ yum install postfix cyrus-sasl cyrus-sasl-plain
This configuration uses a made-up mail account, and, as already stated above, uses the 1und1 SMTP server to relay outgoing mail.
First and foremost, a password file needs to be created so that Postfix can authenticate to the SMTP server. This is done by creating a file named
/etc/postfix. Replace smtp_user and smtp_passwd with their respective values for your account:
$ echo "smtp.1und1.de smtp_user:smtp_passwd" > /etc/postfix/sasl_passwd
The username in this case would be something like
Now we must convert
/etc/postfix/sasl_passwd into a format that Postfix can read:
$ postmap hash:/etc/postfix/sasl_passwd
The above command will create a file named
sasl_passwd.db in the
And for additional security purposes, only root should have access to the password files:
$ chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db $ chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
After all of those steps are completed, we now configure the main configuration file located under
relayhost and set it to the SMTP server address.
relayhost = smtp.1und1.de:587
Finally add the following lines to the configuration file:
smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_use_tls = yes
Keep in mind, that some mail providers force you to use certain security options.
Start or restart Postfix:
$ systemctl start postfix
Draft! This guide is work in progress.
Uploading files to production level after every change in code can be quite a hassle. Most people would use an automated deployment system instead of doing it manually. We can create an automated deployment system ourself by just using a version control like Git, which would also only take a few seconds to set up.
This post outlines the exact steps on how to do that. You should be able to understand basic terminology like
Install Git on the server- and client-side.
$ yum install git-core
Head to this page if you still don’t know how to install it.
You’ll want to start by creating a bare repository on your server. A folder without its actual source files. The repository should be set up somewhere outside of your web root. We are going to instruct Git where to put the actual files later. Once you decide on a location for your repository, go ahead and create the bare repository:
mkdir mysite.git cd mysite.git git init --bare
Now we need to instruct Git where to put the files after every commit. This can be done via hooks, basically actions defined by triggers.
Head to this page to read more about hooks.
Create a file named
post-receive in the
.git/hooks directory of your bare repository with the following content (replace the destination path as you see fit):
#!/bin/sh GIT_WORK_TREE=/var/www/mysite git checkout -f
Once this is done, mark it as executable:
$ chmod +x post-receive
Git is going to put the files after every push directly to the destination folder (e.g.
Now setup Apache Webserver, Nginx or whatever you use to serve your site from the destination folder.
Proceed to create the local repository and make the first commit and push by adding the remote repository we created:
$ git init $ git add . $ git commit -m "First commit" $ git remote add live ssh://username@ip:port/path/to/mysite.git $ git push live master
Now every commit and push, as in every change you make on your local repository, will immediately affect the live environment. Not even a manual pull has to be executed!