1) Machine Catalogs
2) Delivery Groups
3) Application Deployment ( Need to install the VDA for the server to be registered)
Existing install : 6.1.1-207789
Upgrade : 126.96.36.199098
- First, create a backup of the entire Splunk folder. In theory, the /etc and it’s sub-folders would be sufficient, but a full backup can’t hurt.
- Download the new source files. The Splunk developers have been kind enough to provide a wget friendly link. Simply click the “Download” button and look at the next page.
- Extract (tar -xvf) the splunk folder.
- Copy that entire folder over your previous installation. You can use ” yes | cp -r source_path destination_path” to answer yes to all the overwrite prompts.
- That’s it!
yum install easy-rsa
Default Directory : /usr/share/easy-rsa/2.0/
vim ./vars [Edit the files with the correct values for your authority]
source ./vars [Export the variables]
./clean-all [Optional : Remove any old CA you might have created]
./build-key-server ServerName [CommonName = ServerName]
./build-dh [Create a Diffie-Hellman key]
./build-key NameClient [CommonName = NameClient]
SSH is secure! I don’t need anything else!
Well, you are not exactly wrong. But security is not something that should be taken lightly.
I’ve recently acquired a Linode host and I was stunned by the number of unauthorized login attempts. About 99% of those attempts were probably automated scripts crawling the Internet for anything responding to queries on port 22. I believe that a huge part of modern “hacking” is entirely automated which reinforces the perspective that security is a 24/7 concern.
Since SSH is your main entry point to control your machine, it’s especially critical that it’s well protected. Private/public key authentication allows you to login into your machine without providing a password.
Here is a very basic overview.
You first create a key pair : Private and Public key. The private key allows you to apply your “signature” to content. The only way to verify that signature is to have your Public key. You then transfer that public key file unto your server. When you try to connect to the server using your Private key, the server will try to match the unique signature using the Public key you had previously transferred. That entire operation completely removes the need to transfer a password. It’s almost much more complex to brute-force.
That said, it’s up to you to protect your private key. I recommend adding a passphrare during the key generation. Without that extra step, both the public and private key would both be written in clear-text.
China is knocking…
Jun 16 02:12:30 li362-86 sshd: Failed password for root from 188.8.131.52 port 32848 ssh2 Jun 16 02:12:31 li362-86 sshd: Failed password for root from 184.108.40.206 port 29883 ssh2 Jun 16 02:12:32 li362-86 sshd: Failed password for root from 220.127.116.11 port 32848 ssh2 Jun 16 02:12:34 li362-86 sshd: Failed password for root from 18.104.22.168 port 29883 ssh2 Jun 16 02:12:34 li362-86 sshd: Failed password for root from 22.214.171.124 port 32848 ssh2 Jun 16 02:12:36 li362-86 sshd: Failed password for root from 126.96.36.199 port 29883 ssh2
Prerequisites : This guide was performed on a CentOS 6.5 machine with almost no extra packages. Most, if not all commands, should be the same on Debian based OS. That said, be aware that you will have to substitute your own folder and files path. Any variable you need to replace with your own will be marked with the “$” sign.
chmod 700 /home/$USER/.ssh
chmod 600 /home/$USER/authorized_keys
Folder has to be owned by the appropriate user attempting to log in.
Mumble – Open source voice server
Django Mumble – Open source django based administration interface
Cisco Etherchannel – LACP and PAGP
CentOS 6.5 – Nfsen and Nfdump