Category Archives: OS

grant permissions to windows cluster object via the container to enable MSSQL Cluster installation.

CNO = When the Windows Failover Cluster (WFC) is initially configured a Cluster Name object (CNO) will be created. this is the windows cluster object in the AD.

1. Open the Active Directory Users and Computers Snap-in (dsa.msc).

2. Locate “Computers” container:

3. Make sure “Advanced Features” is selected:

4. Open the properties of the container and click the “Security” tab. Click “Add” and add the CNO. Make sure to select “Computers” option in the “Object Types” window:

5. Click “Advanced”, highlight the CNO, and click “Edit”:

6. Make sure “Read all properties” and “Create Computer objects” are checked. Click OK until you’re back to the AD Users and Computer window:

7. Retry your previously failed installation. Note that with SQL Server 2012 there will be a “retry” button.

via Error during installation of an SQL server Failover Cluster Instance – CSS SQL Server Engineers

Which Files Should You Back Up On Your Windows PC?

via Which Files Should You Back Up On Your Windows PC?

Your PC’s hard drive could fail tomorrow, or a software bug could erase your files, so backups are critical. But you don’t need to back up all the files on your PC. That would just waste space and make your backups take longer to complete.

The All-Important Rule of Backups

The most important rule of backups is that any important data should exist in two or more physical locations at once. You cannot create a backup and delete the original. If you do, it’s no longer really a backup. You still have just one copy of your data—you just moved it to a different place.

You might think this is obvious, but you’d be surprised how often we’ve been approached by readers that lost their data after their “backup” drive died.

There are many ways to back up your data, from backing up to an external drive to uploading copies of your data to a remote server over the Internet. You can use the tools integrated into Windows or download a third-party backup tool. Choose the best backup solution that works for you—we discuss some of our favorites here.

We also recommend using multiple types of backups for maximum data security. For example, if you store your sole backup drive next to your computer, you’ll lose all copies of your files if your hardware is ever stolen or damaged in a fire. So having a backup in the cloud is a good idea.

Back Up Your Files, Not Your Full System

There are two types of backups you can create. Most common backup tools will back up a list of files and folders you specify. This allows you to back up just the files and folders you need. Your backups won’t be any larger than they need to be, and they’ll complete quickly.

However, it’s also possible to create full system image backups of your computer’s hard drive using built-in or third-party tools. These will back up everything, from your Windows system directory and installed program files to your personal data. These backups will be much larger and take much longer to create.

For most people, we recommend you stick with just backing up your files and folders. System image backups sound nice, but there are some big catches. For example, you can’t easily restore a system image on another computer, as a Windows installation will generally only run properly on its original system. You’re better off just starting from a fresh Windows installation and reinstalling your programs.

System image backups have their place, but avoid them unless you’re sure you need them. They’re not the best general purpose backup solution.

Files You Should Back Up

The most important thing is to back up your personal files. On a modern Windows PC, you’ll generally find these under C:\Windows\USERNAME, where USERNAME is your user account name.

By default, this directory contains your user account’s data folders. These include the Documents folder where your documents are saved to by default, the Pictures folder that likely contains any family photos you have, the Downloads folder where files are downloaded, the Music folder where your music files are probably stored, and the Videos folder where videos are stored. If you use iTunes for your music, iTunes stores its music library in your music folder by default. It even includes your Desktop folder, where many people store files.

It also includes other important folders, like OneDrive, Dropbox, and Google Drive, where offline copies of your cloud files are stored if you use these services.

There’s also an AppData folder here, but you won’t see it unless you’re showing hidden files and folders. This is where programs store the settings and data specific to your user account. You may be able to use this data to restore an individual program’s settings if you ever need to recover from a backup.

With that in mind, we recommend you back up your entire user account directory, including the hidden AppData folder. This ensures you have all your personal files and settings, and you don’t have to spend much time thinking about it. If multiple people use the same PC and have their own files, back up each user account’s folder.

You may choose to exclude certain folders from the backup if you don’t want them present. For example, if you store a bunch of downloaded videos in the Videos folder and you don’t mind redownloading them in the future, exclude it from the backup. If you have a many gigabytes of virtual machines that take a large amount of space and you wouldn’t mind setting them up from scratch again, exclude the virtual machine folder. But, if those virtual machines are important and it would take you a good amount of time to configure them again, you probably want to back them up.

You’ll notice that we’re using a lot of words like “by default”, “likely”, and “probably” when saying where your files are stored. That’s because Windows lets you store your files in any location you like. If you moved them, only you know where all your files are stored.

For example, it’s easy to move a folder like Music, Videos, Downloads, Pictures, or Documents to another location on your PC. These files may be stored on another drive, for example. Or you may not use the default folders at all and simply dump files in a folder elsewhere on your PC’s hard drive. If you store your files in non-standard locations like this, it’s crucial you identify the folders containing your important files and add them to the backup.

Your browser’s bookmarks and other settings are located somewhere in the AppData folder, so backing up your entire user folder will save these files as well. However, you may want to use your browser’s sync feature and sync its settings with a Google, Firefox, or Microsoft account. This will save you from having to dig through your AppData folder.

If you use a desktop email client, you may also want to back up your emails. This isn’t necessary if you use the modern IMAP protocol for your email, as the master copies of your emails are still stored on the remote server. However, if you’ve downloaded emails via the POP3 protocol, it’s crucial you back up your emails as they may only be stored on your PC.

The good news is that your emails are likely stored in your user account’s AppData folder, so they’ll be automatically backed up if you back up your entire user folder. You may still want to check the location of your email files just to ensure they’re backed up, however. Here’s how to find the location where Outlook stores your emails.

Any other personal data and settings that aren’t located in your user account folder should be backed up, if you care about it. For example, you may want to back up application settings that are located in the C:\ProgramData folder for some applications.

PC games in particular have files all over the place. Many games synchronize their save files online using Steam Cloud or a similar service, so they won’t need backups. Many store their save games in your Documents or AppData folders, while others dump their save games in C:\ProgramData or another location, like somewhere in your Steam folder. The PCGamingWiki website has a good database of games with information about whether they synchronize their save games or not and exactly where their save files are located on your PC.

Ensure whatever data you care about—whether it’s your family photos, settings for a mission-critical application, or save games for that RPG you’ve been playing for 100 hours—is backed up.

Files You Shouldn’t Back Up

There’s never a reason to back up your Windows directory or Program Files folder. Leave these folders alone.

The Windows directory contains Windows system files, and they aren’t portable between different PC hardware. Windows will set up these files when it’s installed on a new PC, so you don’t need them.

The Program Files folder contains files for your installed applications. You usually can’t just copy these folders over. You’ll have to reinstall most applications from scratch, so there’s generally no point in backing up this folder.

A handful of programs can be simply moved between PCs. For example, you can back up your Steam or Battle.net directories and copy them over to a new PC, saving the big download of these games. However, even these folders aren’t critical to back up. They can make setting up a new PC faster and save some of download time, but they aren’t full of critical files you can never get back. You can always just reinstall your programs, so they aren’t the priority if you’re limited on space.

Back Up Regularly

Once you’ve started backing up your files, you should continue creating regular backups. Back up your files daily, if possible. This will be a fast process if you back up regularly, as your backup tool will just back up the few personal files that have changed.

Automating your backups helps ensure those backups get performed regularly. That’s one reason why online backup solutions are so good. They can be configured to automatically back up your PC every day when you aren’t using your computer, so you won’t even have to think about it.

Extend a logical volume in a virtual machine running Red Hat or Cent OS

Source: Extending a logical volume in a virtual machine running Red Hat or Cent OS (1006371) | VMware KB

By default installation, Linux virtual machine (Fedora, RHEL or CentOS) has two partitions, one for swapping, and the other one is a lv (Logic Volume) partition.

The LVM (Logic Volume Manager) partition mount as /, and cannot be resized by partition tools such as partition magic or gparted.

To extend the logical volume:

Note: These steps only apply to EXT3 file systems.

 

Caution: VMware recommends to take a complete backup of the virtual machine prior to making these changes.

  1. Power off the virtual machine.
  2. Edit the virtual machine settings and extend the virtual disk size. For more information, see Increasing the size of a virtual disk (1004047).
  3. Power on the virtual machine.
  4. Identify the device name, which is by default /dev/sda, and confirm the new size by running the command:

    # fdisk -l

  5. Create a new primary partition:
    1. Run the command:

      # fdisk /dev/sda (depending the results of the step 4)

    2. Press p to print the partition table to identify the number of partitions. By default, there are 2: sda1 and sda2.
    3. Press n to create a new primary partition.
    4. Press p for primary.
    5. Press 3 for the partition number, depending on the output of the partition table print.
    6. Press Enter two times.
    7. Press t to change the system’s partition ID.
    8. Press 3 to select the newly creation partition.
    9. Type 8e to change the Hex Code of the partition for Linux LVM.
    10. Press w to write the changes to the partition table.
  6. Restart the virtual machine.
  7. Run this command to verify that the changes were saved to the partition table and that the new partition has an 8e type:

    # fdisk -l

  8. Run this command to convert the new partition to a physical volume:

    Note: The number for the sda can change depending on system setup. Use the sda number that was created in step 5.

    # pvcreate /dev/sda3

  9. Run this command to extend the physical volume:

    # vgextend VolGroup00 /dev/sda3

    Note: To determine which volume group to extend, use the command vgdisplay.

  10. Run this command to verify how many physical extents are available to the Volume Group:

    # vgdisplay VolGroup00 | grep “Free”

  11. Run the following command to extend the Logical Volume:

    # lvextend -L+#G /dev/VolGroup00/LogVol00

    Where # is the number of Free space in GB available as per the previous command. Use the full number output from Step 10 including any decimals.

    Note: To determine which logical volume to extend, use the command lvdisplay.

  12. Run the following command to expand the ext3 filesystem online, inside of the Logical Volume:

    # ext2online /dev/VolGroup00/LogVol00

    Notes:

    • Use resize2fs instead of ext2online if it is not a Red Hat virtual machine.
    • By default, Red Hat and CentOS 7 use the XFS file system you can grow the file system by running the xfs_growfs command.
  1. Run the following command to verify that the / filesystem has the new space available:

    # df -h /

How to manage vmware ESX with PowerShell

  1. Prerequisites:
    • Windows .Net Framework 2.0 (3.5 latest SP Recommended).
    • Windows PowerShell (V2 Recommended).
  2. Install vSphere client.
  3. Set the ‘Execution Policy’ of PowerShell to Remote Signed.
    • Run PowerShell as administrator.
    • Set-ExecutionPolicy RemoteSigned
  4. Type Exit and press Enter to leave the PowerShell prompt.
  5. Do it on both PowerShell consoles: x86 and x64.
  6. Download the PowerCLI software to your workstation from the following URL: http://vmware.com/go/PowerCLI
  7. Run the PowerCLI exe file.
  8. Install it all the way with default values. Click next until you arrived to finish screen and click finish.
  9. On your desktop you will now have two icons, which allow you to launch PowerCLI, a 64 bit version and a 32 bit version.
  10. Copy the PowerCLI modules folder to the PowerShell modules folder:
  11. C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Modules -> C:\Windows\System32\WindowsPowerShell\v1.0\Modules
  12. View the new vmware modules: Get-Module -ListAvailable | ? {$_.name -like “*VMware*”}
  • Example

C:\WINDOWS\system32> Get-Module -ListAvailable | ? {$_.name -like “*VMware*”}

    Directory: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\PowerCLI\Modules

ModuleType Version    Name                                ExportedCommands

———- ——-    —-                                —————-

Binary     6.0.0.0    VMware.DeployAutomation

Binary     6.0.0.0    VMware.ImageBuilder

Binary     6.5.0.4… VMware.VimAutomation.Cis.Core

Binary     6.5.0.4… VMware.VimAutomation.Cloud

Manifest   6.5.0.4… VMware.VimAutomation.Common

Binary     6.5.0.2… VMware.VimAutomation.Core           HookGetViewAutoCompleter

Binary     6.0.0.0    VMware.VimAutomation.HA

Binary     7.0.2.4… VMware.VimAutomation.HorizonView

Binary     6.5.0.4… VMware.VimAutomation.License

Binary     6.5.0.4… VMware.VimAutomation.PCloud

Manifest   6.5.0.4… VMware.VimAutomation.Sdk            Get-PSVersion

Binary     6.5.0.4… VMware.VimAutomation.Storage

Binary     6.5.0.4… VMware.VimAutomation.Vds

Binary     6.5.0.4… VMware.VimAutomation.vROps

Binary     6.0.0.0    VMware.VumAutomation

  1. Import the modules you need: Import-Module -Name VMware.VimAutomation.Core
  2. The end.

Source: Back to Basics: Part 1 – Installing PowerCLI – VMware PowerCLI Blog – VMware Blogs

https://blogs.vmware.com/PowerCLI/2015/03/powercli-6-0-introducing-powercli-modules.html

How to add ISCSI disk to Ubuntu server from NetApp

General info

Target = storage system. In this case NetApp.

Initiator = the server. In this case Ubuntu Linux server.

Change iqn name = You must supply the iSCSI initiator node name when you set up igroups.

To make this process go smoothly, it is a good practice to write down the node name now. Before you record the node name, you might want to change it.

By default, a node name ends with a string of random numbers.

Changing this part of the name to something such as the host name can make the node name easier to use.

Note! You can only change the last portion of the iqn name: like change the name form iqn.2005-03.com.RedHat:012345 to iqn.2005-03.com.RedHat:Toaster.

On the Linux server

  1. Install open-iscsi
    1. sudo apt install open-iscsi
  2. Change iqn name to iqn format with the server name at the end
    1. sudo vi /etc/iscsi/initiatorname.iscsi
  3. Edit iscsi config file so that the server connects automatically to the Netapp after reboot.
    1. sudo vi /etc/iscsi/iscsid.conf
    2. change the folowing line to automatic:
    3. startup = automatic
  4. Restart the iscsi service
    1. sudo systemctl restart iscsid
  • go to Netapp steps. When done, comeback here.
  1. Rediscover the Netapp
    1. sudo iscsiadm -m discovery -t sendtargets -p 192.168.1.53
  2. Connect to the netapp
    1. sudo iscsiadm -m node –login
  3. Get the list of disks on the server and locate the new ISCSI disk
    1. dmesg | grep sd
  4. Create a new partition
    1. sudo fdisk /dev/sdb
    2. n (Add new partition).
    3. P (Primery partition).
    4. enter
    5. w (Write table to disk and exit).
  5. Format the file system and mount it to /srv
    1. sudo mkfs.ext4 /dev/sdb1
    2. sudo mount /dev/sdb1 /srv
  6. Add an entry to /etc/fstab file – to mount the iscsi drive during boot:
    1. /dev/sdb1 /srv        ext4    defaults,auto,_netdev 0 0
  7. Reboot the server and verify that the disk is automatically up.
    1. sudo reboot -h now
    2. df -h

 

  • If for some reason you want to disconnect from the Netapp which means to disconnect the ISCSI disk from the server, you can logout with:
    1. sudo iscsiadm -m node –logout
  • If for some reason you want to uninstall open-iscsi package from the server, you can do it with:
    1. service open-iscsi stop
    2. sudo apt-get remove –auto-remove open-iscsi
    3. sudo reboot
    4. sudo apt-get purge open-iscsi

On the Netapp storage

  1. Create new volume
  2. Create new qutree
  3. Create new LUN
  4. Create new initiator group
  5. Add the Linux server initiator name to the initiator group
    1. You can get the initiator name by going to the Linux server and look in the initiator config file: sudo cat /etc/iscsi/initiatorname.iscsi

Sources:

(iSCSI) How to configure iSCSI for Linux

https://help.ubuntu.com/lts/serverguide/iscsi-initiator.html#iscsi-initiator-install

http://installion.co.uk/ubuntu/trusty/main/o/open-iscsi/uninstall/index.html

https://www.howtogeek.com/106873/how-to-use-fdisk-to-manage-partitions-on-linux/

Give people delegate permissions for a distribution group Office 365

 

 

Give people delegate permissions for a distribution group

If you are an Office 365 admin, you can give people delegate permissions to send email from, and on behalf of a distribution group.

  1. Log in to your office 365 admin center.
  2. Click the Admin tile.
  3. In the Office 365 admin center panel, click Groups.
  4. In the Groups panel, check the box next to the group you want to add delegates to.
  5. In the right panel, under Distribution list, click Edit Exchange properties.
  6. Click group delegation.
  7. Use the following to help you determine whether you want to assign Send As or Send on Behalf permissions

Send As:

This allows a member of the group to send email as the distribution group address. To a recipient, the From line will display the group name only.

Send on Behalf:

This allows a member of the group to send email on behalf of the group. To a recipient, the From line will display the sender “on behalf of” the group.

To send as the distribution group, you need to show the From field in your email composer. To show the From field in Outlook, open a new email, click Options, and select From.

Source: Give people delegate permissions for a distribution group | Office 365 from GoDaddy – GoDaddy Help GB

How to Check MD5 checksum of a File on Windows

What is MD5 Sum?

MD5 is a widely known term in the tech world but if you are an active Android users, you must have confronted the terms like “md5sum”, “md5 hash” or “md5 checksum” quite frequently. Most official and custom ROMs, mods and recovery flushable ZIPs come pre-encrypted with a unique code for security reasons. It’s a kind of password that is used to ensure the integrity of files inside a ZIP or a software package.

An MD5 checksum is a mathematical algorithm is usually a set of 32-character hexadecimal letters and numbers that are computed on a file with a tool. These numbers are generated using special tools that employ “cryptographic hash function producing a 128-bit (16-byte) hash value”. It is used not only to encrypt a ZIP archive or an EXE installer but all kinds of files. You can assign an MD5 sum even to a text or document file. The perfect match of MD5 checksum value ensures that the digital integrity and security of a file has not been broken by someone else and also that it is the accurate copy of the original file.

Thus, there are the two main reasons if the MD5 hash value of a file you downloaded does not match against the original sum:

  1. The file might be modified by someone else in an unauthorized way.
  2. The file was not downloaded properly and some of its elements might have been corrupted.

The MD5 checksum or hash value of a file might look like these:

25912deacc5d55528e223ec7b99705cc

220c41f3b03f42190899db8cb081b5c6

a578d837343fe2542ecf405a630d46a0

8223ec1c2aa71503b431a0daabb23154

Why to Verify MD5?

Installing an official firmware, a custom ROM or even a Kernel file with corrupt MD5 value can lead to a bricked phone or tablet. It is, therefore, very important that whenever you download such files with a purpose to install them on your device, make sure to compare/match the computed MD5 checksum against the one provided on the download page to verify their integrity. I have seen various cases where people report that their device went to bricked state after installing a certain file. In many cases, you might get an installation failed error if the MD5 hash value is not correct.

It is a customary practice among Android developers to mention the MD5 sum of their ROMs, mods, and kernels when they share them. Having downloaded such files, you can run an MD5 checker program on your computer to match the MD5 value. It the sum matches perfectly; you can proceed to install the file. In case there is a mismatch between the values, you should avoid installing such files.

To make sure that it is just a case of bad download, try downloading the file again, preferably from a different mirror or browser. If the match fails again, contact the developer and report it. He/she might check if the MD5 they provided was correct or give you an alternate link to get the file.

Verify MD5 Checksum on Windows

If you are a Windows user. you can find a variety of MD5 checksum programs available on the internet that can be used for the purpose. Personally, I use a very nice and easy to use a tool called WinMD5Free. Here is how you can use it to verify:

  1. Download the latest version of WinMD5Free from the official site: Click Here  [mirror]
  2. Extract the downloaded zip and launch the WinMD5.exe file.
  3. Click on the Browse… button, navigate to the file that you want to check and select it.
  4. Just as you select the file, the tool will show you its MD5 checksum.
  5. Now copy and paste the original MD5 value provided by the developer or the download page in the box below.
  6. Then click on Verify button.
  1. The tool will then give you the match results and shown above.

How to Check/ Verify MD5 CheckSum of a File on Windows, Mac and Linux

How to Monitor haproxy with Cacti

How to Monitor haproxy with Cacti

Install package

yum install net-snmp net-snmp-utils –y

Verify installation

rpm -qa | grep net-snmp*

net-snmp-agent-libs-5.7.2-24.el7.x86_64

net-snmp-5.7.2-24.el7.x86_64

net-snmp-libs-5.7.2-24.el7.x86_64

net-snmp-utils-5.7.2-24.el7.x86_64

Edit SNMP configuration file

vi /etc/snmp/snmpd.conf

rocommunity   ec1980

syscontact Root <root@localhost> (configure /etc/snmp/snmp.local.conf)

view    systemview    included   .1.3.6.1.2.1.1

view    systemview    included   .1.3.6.1.2.1.25.1.1

access  notConfigGroup “”      any       noauth    exact  systemview none none

disablePerl false

perl do ‘/etc/snmp/haproxy.pl’;

Open firewall UDP port 161

firewall-cmd –permanent –add-port=161/udp

firewall-cmd –reload

firewall-cmd –list-all

systemctl stop firewalld

systemctl disable firewalld

Start SNMP service

systemctl start snmpd

systemctl enable snmpd

Edit haproxy configuration file # Global settings

vi /etc/haproxy/haproxy.cfg

#———————————————————————

# Global settings

#———————————————————————

global

 

    # to have these messages end up in /var/log/haproxy.log you will

    # need to:

.

.

.

.

 

#    stats socket /var/lib/haproxy/stats

stats socket /var/run/haproxy.stat mode 666

Download haproxy installation files from haproxy website to /tmp folder

cd /tmp/

wget http://www.haproxy.org/download/1.5/src/haproxy-1.5.16.tar.gz

tar zxvf haproxy-1.5.16.tar.gz

cd haproxy-1.5.16

cd contrib

cd netsnmp-perl

Copy haproxy.pl to snmp folder

 cp haproxy.pl /etc/snmp/

Install perl-Net-SNMP package

yum provides ‘*/Net/SNMP.pm’

yum install epel-release

yum install perl-Net-SNMP

Verify Installation

rpm -qa | grep net-snmp*

net-snmp-agent-libs-5.7.2-24.el7.x86_64

net-snmp-5.7.2-24.el7.x86_64

net-snmp-perl-5.7.2-24.el7.x86_64

net-snmp-libs-5.7.2-24.el7.x86_64

net-snmp-utils-5.7.2-24.el7.x86_64

Restart snmp service

systemctl restart snmp

Restart haproxy service

service haproxy restart

Validate haproxy perl script

perl /etc/snmp/haproxy.pl # even if this doesn’t work check that the query works.

Validate internal SNMP query works

snmpwalk -v 1 -c ec1980 -O e 127.0.0.1

snmpbulkwalk -c ec1980 -v2c 127.0.0.1 1.3.6.1.4.1.29385.106.2.0

Copy cacti XML files from haproxy installation files to cacti resource folders

C:\inetpub\wwwroot\cacti\resource\snmp_queries

cacti_data_query_haproxy_backends.xml

cacti_data_query_haproxy_frontends.xml

haproxy_backend.xml

haproxy_frontend.xml

haproxy_socket.xml

C:\inetpub\wwwroot\cacti\resource\script_queries

haproxy_backend.xml

haproxy_frontend.xml

haproxy_socket.xml

C:\inetpub\wwwroot\cacti\resource\script_server

haproxy_backend.xml

haproxy_frontend.xml

haproxy_socket.xml

Add data query and graphs

Finish!

How To Configure BIND as a Private Network DNS Server on CentOS 7

How To Configure BIND as a Private Network DNS Server on CentOS 7

Introduction

An important part of managing server configuration and infrastructure includes maintaining an easy way to look up network interfaces and IP addresses by name, by setting up a proper Domain Name System (DNS). Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases the configuration of services and applications, and increases the maintainability of configuration files. Setting up your own DNS for your private network is a great way to improve the management of your servers.

In this tutorial, we will go over how to set up an internal DNS server, using the BIND name server software (BIND9) on CentOS 7, that can be used by your Virtual Private Servers (VPS) to resolve private host names and private IP addresses. This provides a central way to manage your internal hostnames and private IP addresses, which is indispensable when your environment expands to more than a few hosts.

Prerequisites

To complete this tutorial, you will need the following:

  • Some servers that are running in the same datacenter and have private networking enabled
  • A new VPS to serve as the Primary DNS server, ns1
  • Optional: A new VPS to serve as a Secondary DNS server, ns2
  • Root access to all of the above.

Example Hosts

For example purposes, we will assume the following:

  • We have two existing VPS called “host1” and “host2”
  • Both VPS exist in the nyc3 datacenter
  • Both VPS have private networking enabled (and are on the 10.128.0.0/16 subnet)
  • Both VPS are somehow related to our web application that runs on “example.com”

With these assumptions, we decide that it makes sense to use a naming scheme that uses “nyc3.example.com” to refer to our private subnet or zone. Therefore, host1‘s private Fully-Qualified Domain Name (FQDN) will be “host1.nyc3.example.com”. Refer to the following table the relevant details:

Host Role Private FQDN Private IP Address
host1 Generic Host 1 host1.nyc3.example.com 10.128.100.101
host2 Generic Host 2 host2.nyc3.example.com 10.128.200.102

Note: Your existing setup will be different, but the example names and IP addresses will be used to demonstrate how to configure a DNS server to provide a functioning internal DNS. You should be able to easily adapt this setup to your own environment by replacing the host names and private IP addresses with your own. It is not necessary to use the region name of the datacenter in your naming scheme, but we use it here to denote that these hosts belong to a particular datacenter’s private network. If you utilize multiple datacenters, you can set up an internal DNS within each respective datacenter.

Our Goal

By the end of this tutorial, we will have a primary DNS server, ns1, and optionally a secondary DNS server,ns2, which will serve as a backup.

Here is a table with example names and IP addresses:

Host Role Private FQDN Private IP Address
ns1 Primary DNS Server ns1.nyc3.example.com 10.128.10.11
ns2 Secondary DNS Server ns2.nyc3.example.com 10.128.20.12

Let’s get started by installing our Primary DNS server, ns1.

Install BIND on DNS Servers

Note: Text that is highlighted in red is important! It will often be used to denote something that needs to be replaced with your own settings or that it should be modified or added to a configuration file. For example, if you see something like host1.nyc3.example.com, replace it with the FQDN of your own server. Likewise, if you see host1_private_IP, replace it with the private IP address of your own server.

On both DNS servers, ns1 and ns2, install BIND with yum:

  • sudo yum install bind bind-utils

Confirm the prompt by entering y.

Now that BIND is installed, let’s configure the primary DNS server.

Configure Primary DNS Server

BIND’s configuration consists of multiple files, which are included from the main configuration file,named.conf. These filenames begin with “named” because that is the name of the process that BIND runs. We will start with configuring the options file.

Configure Bind

BIND’s process is known as named. As such, many of the files refer to “named” instead of “BIND”.

On ns1, open the named.conf file for editing:

  • sudo vi /etc/named.conf

Above the existing options block, create a new ACL block called “trusted”. This is where we will define list of clients that we will allow recursive DNS queries from (i.e. your servers that are in the same datacenter as ns1). Using our example private IP addresses, we will add ns1ns2host1, and host2 to our list of trusted clients:

/etc/named.conf — 1 of 4

acl “trusted” {

10.128.10.11;    # ns1 – can be set to localhost

10.128.20.12;    # ns2

10.128.100.101;  # host1

10.128.200.102;  # host2

};

Now that we have our list of trusted DNS clients, we will want to edit the options block. Add the private IP address of ns1 to the listen-on port 53 directive, and comment out the listen-on-v6 line:

/etc/named.conf — 2 of 4

options {

listen-on port 53 { 127.0.0.1; 10.128.10.11; };

#        listen-on-v6 port 53 { ::1; };

Below those entries, change the allow-transfer directive to from “none” to ns2‘s private IP address. Also, change allow-query directive from “localhost” to “trusted”:

/etc/named.conf — 3 of 4

options {

allow-transfer { 10.128.20.12; };      # disable zone transfers by default

allow-query { trusted; };  # allows queries from “trusted” clients

At the end of the file, add the following line:

/etc/named.conf — 4 of 4

include “/etc/named/named.conf.local”;

Now save and exit named.conf. The above configuration specifies that only your own servers (the “trusted” ones) will be able to query your DNS server.

Next, we will configure the local file, to specify our DNS zones.

Configure Local File

On ns1, open the named.conf.local file for editing:

  • sudo vi /etc/named/named.conf.local

The file should be empty. Here, we will specify our forward and reverse zones.

Add the forward zone with the following lines (substitute the zone name with your own):

/etc/named/named.conf.local — 1 of 2

zone “nyc3.example.com” {

type master;

file “/etc/named/zones/db.nyc3.example.com”; # zone file path

};

Assuming that our private subnet is 10.128.0.0/16, add the reverse zone by with the following lines (note that our reverse zone name starts with “128.10” which is the octet reversal of “10.128”):

/etc/named/named.conf.local — 2 of 2

zone “128.10.in-addr.arpa” {

type master;

file “/etc/named/zones/db.10.128”;  # 10.128.0.0/16 subnet

};

If your servers span multiple private subnets but are in the same datacenter, be sure to specify an additional zone and zone file for each distinct subnet. When you are finished adding all of your desired zones, save and exit the named.conf.local file.

Now that our zones are specified in BIND, we need to create the corresponding forward and reverse zone files.

Create Forward Zone File

The forward zone file is where we define DNS records for forward DNS lookups. That is, when the DNS receives a name query, “host1.nyc3.example.com” for example, it will look in the forward zone file to resolve host1‘s corresponding private IP address.

Let’s create the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/named/zones:

  • sudo chmod 755 /etc/named
  • sudo mkdir /etc/named/zones

Now let’s edit our forward zone file:

  • sudo vi /etc/named/zones/db.example.com

First, you will want to add the SOA record. Replace the highlighted ns1 FQDN with your own FQDN, then replace the second “nyc3.example.com” with your own domain. Every time you edit a zone file, you should increment the serial value before you restart the named process–we will increment it to “3”. It should look something like this:

/etc/named/zones/db.nyc3.example.com — 1 of 3

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (

3         ; Serial

604800     ; Refresh

86400     ; Retry

2419200     ; Expire

604800 )   ; Negative Cache TTL

After that, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are “NS” records:

/etc/named/zones/db.nyc3.example.com — 2 of 3

; name servers – NS records

IN      NS      ns1.nyc3.example.com.

IN      NS      ns2.nyc3.example.com.

Then add the A records for your hosts that belong in this zone. This includes any server whose name we want to end with “.nyc3.example.com” (substitute the names and private IP addresses). Using our example names and private IP addresses, we will add A records for ns1ns2host1, and host2 like so:

/etc/named/zones/db.nyc3.example.com — 3 of 3

; name servers – A records

ns1.nyc3.example.com.          IN      A       10.128.10.11

ns2.nyc3.example.com.          IN      A       10.128.20.12

 

; 10.128.0.0/16 – A records

host1.nyc3.example.com.        IN      A      10.128.100.101

host2.nyc3.example.com.        IN      A      10.128.200.102

Save and exit the db.nyc3.example.com file.

Our final example forward zone file looks like the following:

/etc/named/zones/db.nyc3.example.com — complete

  • $TTL 604800
  • @ IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
  • 3       ; Serial
  • 604800     ; Refresh
  • 86400     ; Retry
  • 2419200     ; Expire
  •     604800 )   ; Negative Cache TTL
  • ;
  • ; name servers – NS records
  • IN      NS      nyc3.example.com.
  • IN      NS      nyc3.example.com.
  • ; name servers – A records
  • nyc3.example.com. IN      A       10.128.10.11
  • nyc3.example.com. IN      A       10.128.20.12
  • ; 10.128.0.0/16 – A records
  • nyc3.example.com. IN      A      10.128.100.101
  • nyc3.example.com. IN      A      10.128.200.102

Now let’s move onto the reverse zone file(s).

Create Reverse Zone File(s)

Reverse zone file are where we define DNS PTR records for reverse DNS lookups. That is, when the DNS receives a query by IP address, “10.128.100.101” for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, “host1.nyc3.example.com” in this case.

On ns1, for each reverse zone specified in the named.conf.local file, create a reverse zone file.

Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:

  • sudo vi /etc/named/zones/db.128

In the same manner as the forward zone file, replace the highlighted ns1 FQDN with your own FQDN, then replace the second “nyc3.example.com” with your own domain. Every time you edit a zone file, you should increment the serial value before you restart the named process–we will increment it to “3”. It should look something like this:

/etc/named/zones/db.10.128 — 1 of 3

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (

3         ; Serial

604800         ; Refresh

86400         ; Retry

2419200         ; Expire

604800 )       ; Negative Cache TTL

After that, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are “NS” records:

/etc/named/zones/db.10.128 — 2 of 3

; name servers – NS records

IN      NS      ns1.nyc3.example.com.

IN      NS      ns2.nyc3.example.com.

Then add PTR records for all of your servers whose IP addresses are on the subnet of the zone file that you are editing. In our example, this includes all of our hosts because they are all on the 10.128.0.0/16 subnet. Note that the first column consists of the last two octets of your servers’ private IP addresses in reversed order. Be sure to substitute names and private IP addresses to match your servers:

/etc/named/zones/db.10.128 — 3 of 3

; PTR Records

11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11

12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12

101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101

102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Save and exit the reverse zone file (repeat this section if you need to add more reverse zone files).

Our final example reverse zone file looks like the following:

/etc/named/zones/db.10.128 — complete

  • $TTL 604800
  • @ IN      SOA     example.com. admin.nyc3.example.com. (
  • 3         ; Serial
  • 604800         ; Refresh
  • 86400         ; Retry
  • 2419200         ; Expire
  • 604800 )       ; Negative Cache TTL
  • ; name servers
  • IN      NS      nyc3.example.com.
  • IN      NS      nyc3.example.com.
  • ; PTR Records
  • 10 IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
  • 20 IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
  • 100 IN PTR     host1.nyc3.example.com.  ; 10.128.100.101
  • 200 IN PTR     host2.nyc3.example.com.  ; 10.128.200.102

Check BIND Configuration Syntax

Run the following command to check the syntax of the named.conf* files:

  • sudo named-checkconf

If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. If there are problems with your configuration files, review the error message and the Configure Primary DNS Server section, then try named-checkconf again.

The named-checkzone command can be used to check the correctness of your zone files. Its first argument specifies a zone name, and the second argument specifies the corresponding zone file, which are both defined in named.conf.local.

For example, to check the “nyc3.example.com” forward zone configuration, run the following command (change the names to match your forward zone and file):

  • sudo named-checkzone example.com /etc/named/zones/db.nyc3.example.com

And to check the “128.10.in-addr.arpa” reverse zone configuration, run the following command (change the numbers to match your reverse zone and file):

  • sudo named-checkzone 10.in-addr.arpa /etc/named/zones/db.10.128

When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service.

Start BIND

Start BIND:

  • sudo systemctl start named

Now you will want to enable it, so it will start on boot:

  • sudo systemctl enable named

Your primary DNS server is now setup and ready to respond to DNS queries. Let’s move on to creating the secondary DNS server.

Configure Secondary DNS Server

In most environments, it is a good idea to set up a secondary DNS server that will respond to requests if the primary becomes unavailable. Luckily, the secondary DNS server is much easier to configure.

On ns2, edit the named.conf file:

  • sudo vi /etc/named.conf

Note: If you prefer to skip these instructions, you can copy ns1‘s named.conf file and modify it to listen onns2‘s private IP address, and not allow transfers.
Above the existing options block, create a new ACL block called “trusted”. This is where we will define list of clients that we will allow recursive DNS queries from (i.e. your servers that are in the same datacenter as ns1). Using our example private IP addresses, we will add ns1ns2host1, and host2 to our list of trusted clients:

/etc/named.conf — 1 of 4

acl “trusted” {

10.128.10.11;    # ns1 – can be set to localhost

10.128.20.12;    # ns2

10.128.100.101;  # host1

10.128.200.102;  # host2

};

Now that we have our list of trusted DNS clients, we will want to edit the options block. Add the private IP address of ns1 to the listen-on port 53 directive, and comment out the listen-on-v6 line:

/etc/named.conf — 2 of 4

options {

listen-on port 53 { 127.0.0.1; 10.128.20.12; };

#        listen-on-v6 port 53 { ::1; };

Change allow-query directive from “localhost” to “trusted”:

/etc/named.conf — 3 of 4

options {

allow-query { trusted; }; # allows queries from “trusted” clients

At the end of the file, add the following line:

/etc/named.conf — 4 of 4

include “/etc/named/named.conf.local”;

Now save and exit named.conf. The above configuration specifies that only your own servers (the “trusted” ones) will be able to query your DNS server.

Next, we will configure the local file, to specify our DNS zones.

Save and exit named.conf.

Now edit the named.conf.local file:

  • sudo chmod 755 /etc/named
  • sudo vi /etc/named/named.conf.local

Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is “slave”, the file does not contain a path, and there is a masters directive which should be set to the primary DNS server’s private IP. If you defined multiple reverse zones in the primary DNS server, make sure to add them all here:

/etc/named/named.conf.local

  • zone “example.com” {
  • type slave;
  • file “slaves/db.example.com”;
  • masters { 128.10.11; };  # ns1 private IP
  • };
  • zone “10.in-addr.arpa” {
  • type slave;
  • file “slaves/db.128”;
  • masters { 128.10.11; };  # ns1 private IP
  • };

Now save and exit named.conf.local.

Run the following command to check the validity of your configuration files:

  • sudo named-checkconf

Once that checks out, start BIND:

  • sudo systemctl start named

Enable BIND to start on boot:

sudo systemctl enable named

Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers.

Configure DNS Clients

Before all of your servers in the “trusted” ACL can query your DNS servers, you must configure each of them to use ns1 and ns2 as nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file.

CentOS Clients

On CentOS, RedHat, and Fedora Linux VPS, simply edit the resolv.conf file:

  • sudo vi /etc/resolv.conf

Then add the following lines to the TOP of the file (substitute your private domain, and ns1 and ns2 private IP addresses):

/etc/resolv.conf

search nyc3.example.com  # your private domain

nameserver 10.128.10.11  # ns1 private IP address

nameserver 10.128.20.12  # ns2 private IP address

Now save and exit. Your client is now configured to use your DNS servers.

Ubuntu Clients

On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:

  • sudo vi /etc/resolvconf/resolv.conf.d/head

Add the following lines to the file (substitute your private domain, and ns1 and ns2 private IP addresses):

/etc/resolvconf/resolv.conf.d/head

search nyc3.example.com  # your private domain

nameserver 10.128.10.11  # ns1 private IP address

nameserver 10.128.20.12  # ns2 private IP address

Now run resolvconf to generate a new resolv.conf file:

  • sudo resolvconf -u

Your client is now configured to use your DNS servers.

Test Clients

Use nslookup—included in the “bind-utils” package—to test if your clients can query your name servers. You should be able to do this on all of the clients that you have configured and are in the “trusted” ACL.

Forward Lookup

For example, we can perform a forward lookup to retrieve the IP address of host1.nyc3.example.com by running the following command:

  • nslookup host1

Querying “host1” expands to “host1.nyc3.example.com because of the search option is set to your private subdomain, and DNS queries will attempt to look on that subdomain before looking for the host elsewhere. The output of the command above would look like the following:

Output:

Server:     10.128.10.11

Address:    10.128.10.11#53

 

Name:   host1.nyc3.example.com

Address: 10.128.100.101

Reverse Lookup

To test the reverse lookup, query the DNS server with host1‘s private IP address:

  • nslookup 10.128.100.101

You should see output that looks like the following:

Output:

Server:     10.128.10.11

Address:    10.128.10.11#53

 

11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

If all of the names and IP addresses resolve to the correct values, that means that your zone files are configured properly. If you receive unexpected values, be sure to review the zone files on your primary DNS server (e.g. db.nyc3.example.com and db.10.128).

Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records.

Maintaining DNS Records

Now that you have a working internal DNS, you need to maintain your DNS records so they accurately reflect your server environment.

Adding Host to DNS

Whenever you add a host to your environment (in the same datacenter), you will want to add it to DNS. Here is a list of steps that you need to take:

Primary Nameserver

  • Forward zone file: Add an “A” record for the new host, increment the value of “Serial”
  • Reverse zone file: Add a “PTR” record for the new host, increment the value of “Serial”
  • Add your new host’s private IP address to the “trusted” ACL (conf.options)

Then reload BIND:

  • sudo systemctl reload named

Secondary Nameserver

  • Add your new host’s private IP address to the “trusted” ACL (conf.options)

Then reload BIND:

  • sudo systemctl reload named

Configure New Host to Use Your DNS

  • Configure resolv.conf to use your DNS servers
  • Test using nslookup

Removing Host from DNS

If you remove a host from your environment or want to just take it out of DNS, just remove all the things that were added when you added the server to DNS (i.e. the reverse of the steps above).

Conclusion

Now you may refer to your servers’ private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases maintenance.

Once you have your internal DNS set up, and your configuration files are using private FQDNs to specify network connections, it is critical that your DNS servers are properly maintained. If they both become unavailable, your services and applications that rely on them will cease to function properly. This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them.

Source: How To Configure BIND as a Private Network DNS Server on CentOS 7 | DigitalOcean

Add PowerShell to Windows Explorer Context Menu in Windows 10

Here’s a quick tutorial on how to add PowerShell to the Windows Explorer context menu in Windows 10.

Source: Add PowerShell to Windows Explorer Context Menu in Windows 10 – Petri

1. Open the Registry Editor. You can do this by clicking on Start and typing regedit.

2. Navigate to the following path:

HKEY_CLASSES_ROOT\Directory\Shell

Create a new key by clicking Edit > New > Key.

Call the new key “PowerShell.”

3. Modify the default string in the “PowerShell” key by right-clicking it and selecting “Modify…”

Call the new value “Open PowerShell Here.” Click “OK.

4. In the PowerShell key, create a new key by clicking Edit > New > Key.

5. Call the new key “command.”

6. Modify the default string in the command key by using the following text:

C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoExit -Command Set-Location -LiteralPath ‘%L’

Click “OK.”

7. Add a new string by clicking Edit > New > String value.

Let’s call it “Icon.”

8. Modify the value by using the following text:

“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”,0

Click “OK.”

9. After completing these steps, close the registry, and open Windows Explorer. Go to any folder of your choice and right-click the folder