Add disk to AWS EC2 instance and format as GPT

Add disk to AWS EC2 Linux instance and format as GPT

In AWS:

My assumption is that you have a running instance and are adding a new disk to the running instance.

• Add a new volume and attach it to the EC2 instance.

On the Linux Box:

• lsblk
• This will tell you your new disk ... note /dev/xvdf below

You can find out how your disk is formatted with the command:

gdisk -l /dev/xvdf

So far, no format ... no MBR and no GPT.

Next, we format the disk as GPT format (my disk was 2TB, adjust accordingly)

• parted /dev/xvdf
• (parted) mklabel gpt
• (parted) unit TB
• (parted) mkpart primary 0.00TB 2.00TB
• (parted) print    ....   shows you what you're about to save
• (parted) quit     ....   saves and quits

Now, when you do the lsblk command you'll see /dev/xvdf1 which is a gpt partition:

• lsblk

From here, we make our filesystem (I went with ext4 ... you could just as easily make it xfs):

• mkfs.ext4 /dev/xvdf1

We make the directory we're going to mount to:

• mkdir /data

Now, we need the UUID that goes into /etc/fstab for automount:

• blkid

Now, we edit /etc/fstab with the above UUID:

UUID=99507991-b65f-4199-8ea6-fa7f1bf7856c       /data   ext4    defaults,nofail 0 2

Let's mount it:

• mount -a

Finally, let's double check that the disk is really GPT:

• gdisk -l /dev/xvdf

And, we see that GPT is "present".  Whoo hoo!!

CentOS 7: Moving Active Directory Domains

This goes hand-in-hand with this article:  http://www.mims.me/2016/05/centos-7-ad-authentication.html

1  First, we need to leave the first domain

realm leave -v EXAMPLE.COM

or

realm leave -v EXAMPLE.COM -U <domain admin account>

2.  Next, we need to join the new domain

realm join -v EXAMPLE.COM -U <domain admin account>

3.  If this worked, then go to the article mentioned at the top of the article to set various settings.

4.  I had a lot of trouble with various errors when trying to join my new domain, so here are some places to look if you have trouble.

/etc/samba/smb.conf  ... see if there are ANY references to the OLD domain or OLD DNS servers in this file and modify them to the NEW domain and NEW DNS servers.

If the below doesn't exist, don't add, but in my case it did, so make sure to modify.

[global]

#--authconfig--start-line--

# Generated by authconfig on 2015/08/04 13:08:52

# DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--)

# Any modification may be deleted or altered by authconfig in future

   password server = ADDC1 ADDC2, ADDC3

security = user

   idmap config * : range = 16777216-33554431

   template shell = /bin/bash

   winbind use default domain = false

   winbind offline logon = false

#--authconfig--end-line--

___________________________________________________

/etc/krb5.conf  ... see if there are ANY references to the OLD domain and OLD DNS servers in this file and modify them to the NEW domain and NEW DNS servers

___________________________________________________

If it still doesn't work, run authconfig-tui and use the settings below (obviously modified for your domain):

5.  All you're looking for is that the computer successfully joined the domain.

CentOS 7: AD Authentication

In the past, I always installed pam_ldap and used that authentication method.  In Centos 7 and later, that just wasn't working.

Here's what I did to get user accounts to authenticate against Active Directory.

The RHEL guide for this is at:  https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ch-Configuring_Authentication.html

Here's the definitions of what I'm writing:

example.com - Active Directory domain-name
EXAMPLE.COM - realm-name
server.example.com - Linux computer you're joining to the Active Directory domain


1.  Install realmd (probably already installed) ... if not, yum install realmd

2.  realm discover example.com

# realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common
  login-formats: %U
  login-policy: allow-realm-logins

3.  Get the exact realm-name from the command above

4.  realm join <realm-name> -U <domain admin>

     realm join EXAMPLE.COM -U domainadmin

5.  reboot the linux box

6.  login to the linux box ... as root at this point

7.  Look back at step 2.  In login-formats, %U is specific ... that means just the userid needs to be entered when logging into linux instead of DOMAIN\userid ... step 8 shows how to do that.

8.  To login as just the userid instead of DOMAIN\userid

vi /etc/sssd/sssd.conf

use_fully_qualified_names = False

systemctl restart sssd

9.  realm discover example.com   ... make sure login-formats = %U

# realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common
  login-formats: %U
  login-policy: allow-realm-logins

10.  id <active directory login> (this is an active directory user ... NOT linux) ... you should get back the Active Directory information on the user

11.  Make the users you want sudo capable

vi /etc/group

wheel:x:10:aduser1,aduser2,aduser3

12.  Now the annoying part ... you MUST specify who's allowed to login via the AD userid

To allow ALL users:  realm permit --all

To allow a specific user:  realm permit user@example.com

13.  Reboot

14.  Login via console or ssh with your ad user

Outbound caller ID on IP office

To give credit where credit is due, this article comes from the website http://blogs.scansource.com/avaya-ip-office-caller-id-primer/.  It worked perfectly for me.  Copying it here in case their website goes down.

Avaya IP Office Caller ID Primer

This article explains how to control outbound caller ID on IP Office.

1)   PRI

1. Send out one DID for a group of phones
2. Send out different DIDs for each user

2)   SIP

1. Send out one DID for a group of phones
2. Send out different DIDs for each user

3)   Analog trunks

1) PRICaller ID on a PRI can be controlled using the ARS table or Incoming Call Routes. In most scenarios, the ARS should be used to send out one number for a group of phones, and Incoming Call Routes should be used to send out different Caller ID for each user.

a.   Send out one DID for a group of phonesTo send out one number for all phones, or a group of phones, edit the ARS table as follows.

ARS:

Please note that some carriers require the additional “i” character, which tags the call as national. In those scenarios the Telephone Number field will look like “1Nsi8642861234”.

Short Code:
In scenarios where one group of phones needs to send out one DID, and another group of phones needs to send out a different DID, direct the users to the appropriate ARS table with user short codes. In the example below, when this user dials 9 and any other digits, they are directed to the Line Group ID specified. In this case, the user will be directed to the ARS table 53:PRI, and any caller ID rules configured in that ARS table will be applied to the call. These short codes are applied at the system-wide or user short code level.

b.   Send out different DIDs for each userTo send out each individual user’s DID, the best practice is to edit the Incoming Call Routes for each user.

Incoming Call Route:In the Incoming Number field, add the character “i” (note: lower case) as a prefix, followed by the full ten-digit DID. The user associated with that Incoming Call Route sends the information configured in the Incoming Number field as Caller ID when dialing out. Since the Incoming Number field is matched from right to left, adding all ten digits to the Incoming Number field does not affect inbound routing.

2) SIP Trunks

a.   Send out one DID for a group of phonesTo send out one number for all phones, or a group of phones, the best practice is to add a SIP URI with the full ten-digit DID number that you would like to use for Caller ID in the Local URI, Contact, and Display Name fields.

User Short Code:

Direct the users to the appropriate ARS table with user short codes. In the example below, when this user dials 9 and any other digits, they are directed to the Line Group ID specified. In this case, the user will be directed to the ARS table 52:SIP. These short codes are applied at the system-wide or user short code level.

ARS:

Point the ARS codes to the Line Group ID of the appropriate SIP URI. The caller ID information configured in the SIP URI will be used for all calls routed through this ARS table.

b.   Send out different DIDs for each user

Use Internal Data:

User’s SIP Tab:
With “Use Internal Data” configured in the SIP URI, Caller ID is controlled based on the information configured in each user’s SIP Tab. In the example below, this user sends out “8642861234” as their DID. The ARS table must be configured to use the correct Outgoing Group ID (1 in this case).

3) Analog Trunks

Analog Caller ID is tied to the physical line and cannot be changed at the IP Office level. The line provider is responsible for configuring which Caller ID is sent out.

SSL Certificates: Creating and Converting a PEM file to a P12 file in Linux

First, we'll create the PEM File:

1. Open a new file called filename.pem
2. Import your filename.key (key file)
3. Import your filename.crt (main cert)
4. Import your intermediate.crt (intermediate cert)
5. Import your root.crt (root cert)
6. Make sure there are no spaces between the various certs

Now, the PEM file is ready to use on any Linux box.

To convert the PEM file to a P12 file which can be used on Windows, use the following command:

openssl pkcs12 -export -inkey filename.key -in filename.pem -out filename.p12

NOTE:  You'll see all over the web where people tell you to use -certfile in the command.  That isn't necessary as long as your PEM file has the full certificate chain in it.

To use the .p12 file on Windows, move it to the Windows box and double click on the file ... that will install all the secondary certs into place.  Then, you'll need to do Start --> Run --> MMC and add the snap-in for certificates for the COMPUTER store.  Under the personal certificates, import the .p12 file.

You should be good from here on out.

Cisco 3750X/3750G stack upgrade

Here's the command to upgrade a Cisco Switch stack that is mixed with 3750X switches and 3750G switches:

switch#archive download-sw /allow-feature-upgrade /overwrite 

tftp://<address>/c3750e-universalk9-tar.122-55.SE.tar 

tftp://<address>/c3750-ipservicesk9-tar.122-55.SE.tar

The /allow-feature-upgrade allows you to bypass the new sanity check from 

Cisco if you're trying to change from ipbase to ipservices.

NOTE:  The universal IOS won't work on the 3750Gs 

Get the Serial Number on a Cisco Callmanager

Login to the callmanager via ssh and run the following command to get the serial number of the Callmanager:

utils snmp walk 2c community127.0.0.1 .1.3.6.1.4.1.232.2.2.2.1.0

Make sure to replace community with the proper snmp community string