Monday, February 13, 2017

Updating glance image path in OpenStack CentOS 7

In my lab, I loaded OpenStack Mitaka on my CentOS 7 box.  Everything was pretty much loaded in the root partition because I did not have enough drives and space at the time. Eventually the root partition got 100% full and was throwing all sorts of errors in OpenStack and other places in CentOS. Since I have additional space now so I have to tell OpenStack to start using it.

 

The folders using most of the space was the images directory in the glance folder. I wanted to keep things easy without changing the current path of the folders inside the glance-api.conf file which is /var/lib/glance

 

First I had make the physical volumes then volume group, then I created the logical volumes with the following command.

 

lvcreate -L 200G -n glance cinder-volumes

 

Then formatted it

 

mkfs.xfs /dev/cinder-volumes/glance

 

I zipped up the current images folder and then temporarily moved the files into my home directory and removed the files from their original location

 

tar -cvf images.tar images

mv images.tar /home/

rm -drf /var/lib/glance/images/

 

Backup and edit the /etc/fstab file to mount the new file system by adding the following line

 

/dev/cinder-volumes/glance /var/lib/glance/images                    xfs    defaults        0 0

 

Extrat the files you zipped up earlier then move into the new mounted liv/var/glance/images directory and update the permissions and ownership

 

tar -xvf images.tar                              

chown -R glance:glance /var/lib/glance

 

SElinux will need to update the following to allow us to connect to our newly created path, a shell file was created and can be reused if you need to perform the following on any other directories.

 

#!/bin/bash

set -eu

 

[ -x /usr/sbin/semanage ] || exit 0

 

semanage fcontext -a -t glance_var_lib_t "/var/lib/glance(/.*)?"

restorecon -Rv /var/lib/glance

 

semanage fcontext -a -t glance_log_t "/var/log/glance(/.*)?"

restorecon -Rv /var/log/glance

 

 

Restart the appropriate services and reboot to make sure you can update and add images and it is populating the appropriate directories.

Tuesday, December 13, 2016

Python and NETCONF to manage HP Comware 7

Enterprise networking is evolving and much of it is heading toward automation. One thing I have been coming across regularly is the utilization of API and scripts to assist in building networks. One of the vendors, HP, in Comware 7 allows users to manage their platform utilizing NETCONF protocol.

There is a fair amount of documentation on HP NETCONF; but here is a basic example of how to read a hostname and then modify it utilizing Python and NETCONF

 

NETCONF servers needs to enable on the HP switch and can be done with the following command:

 

netconf ssh server enable 

 

port 830 is the default port it will communicate through.

 

Once this is enabled (and a user account), you can read and write to the device

 

The module used in Python 2.7 is called ncclient and can be installed via PIP install. Here is my output from the interactive shell:

 

 

from ncclient import manager

 

Define the XML path of the information you need to obtain

 

filterget = '<top xmlns="http://www.hp.com/netconf/data:1.0"><Device><Base><HostName></HostName></Base></Device></top>'

 

Build the connection to the device with the data

 

sodarocks = manager.connect(host='192.168.11.15',port=830,username='admin',password='admin',hostkey_verify=False,allow_agent=False,look_for_keys=False, device_params={'name':'hpcomware'})

 

>>> sodarocks.get(('subtree', filterget))

 

The return value will be string in XML format

 

<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns:config="http://www.hp.com/netconf/config:1.0" xmlns:data="http://www.hp.com/netconf/data:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:4486954e-2142-4896-a977-b66a294f4fec"><data><top xmlns="http://www.hp.com/netconf/data:1.0"><Device><Base><HostName>sodas5900</HostName></Base></Device></top></data></rpc-reply>

 

This return value can help you determine the path you need to modify to correct the XML string, in my case, I am looking to change the hostname

 

I will create a new filter with the modifications I want to the hostname:

 

filterchange = '<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><top xmlns="http://www.hp.com/netconf/config:1.0"><Device><Base><HostName>notsodas5900</HostName></Base></Device></top></config>'

 

Then execute the modification using the new filter and the type of operation performed:

 

sodarocks.edit_config(target='running', config=filterchange, default_operation='replace')

 

You should get an rpc ok

 

>>> sodarocks.edit_config(target='running', config=filterchange, default_operation='replace')

 

<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns:config="http://www.hp.com/netconf/config:1.0" xmlns:data="http://www.hp.com/netconf/data:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:03b4f996-d025-4aa7-be5e-782d0a4ffed3"><ok/></rpc-reply>

 

Some additional resources you can look at the is the API documentation that comes with each release of Comware from HP support site and the ncclient reference on github.

 

Wednesday, September 28, 2016

Setting up Windows Server 2008 R2 RADIUS authentication with Juniper SRX

Under Windows Network Policy Server (NPS)

Create a shared secret template, name it SRXpassword or something and make a password.

Create a new network policy and name it, leave the network access server unspecified

 

Click next and select the Windows Group and select the group(s) you want to access the device.

Click next and select access granted

For the type of encryption, click add, select MS-CHAPv2

Do not change anything under the constraint page and click next.

Remove everything from the Standard RADIUS attributes and select the vendor specific type. Click add and select vendor specific

Enter the Juniper vendor code 2636 and click yes it conforms

Put in the vendor-assigned attribute number 1 and select string as the attribute format and type in su

 

Click OK to close it and back to the menu select the encryption type. Uncheck everything except strongest encryption and click next and finished.

 

Create the new RADIUS client and populate the information of your firewall. Select the share secret template you create earlier.

 

On the Juniper SRX Firewall

 

Type in the following and fill in your server IP and password.

set system authentication-order [ password radius ]

set system radius-server 192.168.1.2 secret WhatEverPasswordYouMade

set system radius-options password-protocol mschap-v2

set system login user su class super-user

commit

 

Monday, September 5, 2016

Remotly Downloading Torrents

Lets say you only have ssh connections to your server, and you wanted to download torrents.


Things you will need:


Remote system:

putty or SecureCRT

sftp https://winscp.net/eng/docs/free_sftp_client_for_windows


Linux commands installed:

screen

transmission-cli


1. Download your torrent file.

2. Use sftp to send the file to your BitTorrent file folder.

3. Login to your system

4. Startup screen by typing

 $screen

  This will start a terminal run man screen for more information http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

5. start torrent client

$transmission-cli Example.of.Torrent.file.torrent -w /location/to/save/file

6. Detach from screen session to log off.

hold Ctrl+a  then hit the d key to detach.
This will output a session id <id>.fqdn

7. When you login later

$screen -ls
111111.hostname1
222222.hostname2

8. Connect to screen
$screen -r 111111

Linux job commands:
Ctrl+z will put the job(process) on pause
$bg
Will put the job in the background
$fg
will put the job in the foreground
Ctrl+c will quit the program.

10. After checking the status you can Ctrl+c to end the torrent or Ctrl+a d to detach from screen.

11. To start another screen just type in
$screen
Detach (Ctrl+a d)
$screen -ls
$screen -r <id#>

Please revise for transmission-remote if possible

Friday, September 2, 2016

Virtual firewalls in OpenStack not routing packets properly

So I ran into an issue after loading up a vSRX and virtual F5 Big IP in OpenStack. I setup the virtual appliances as the gateway for my other instances but their packets were not traversing across the other networks if they were routed by my vSRX or vBigIP.

To eliminate all other factors, I went ahead and enable ping on the all interfaces and moved them all into the trusted zone of the SRX. Then I attempted to pings the other interfaces of the firewall that were in the other subnets. They all failed, but the SRX showed that it received the packets and sent the replies. I experience the same thing on the virtual instance of Big IP. That lead me to believe it was failing on the virtual switch in Openstack.

 

It seems port security is enable by default and needs to be disabled in neutron. To do this, perform the following.

Delete any virtual objects that you have created that will need packets routed across your virtual firewall and remove any security groups you have applied to the instance.

Modify the file in /etc/neutron/plugins/ml2/ml2_conf.ini

Right below [ml2] – you will need to add extension_drivers = port_security

# An ordered list of extension driver entrypoints to be loaded from the

# neutron.ml2.extension_drivers namespace. For example: extension_drivers =

# port_security,qos (list value)

extension_drivers = port_security

After this is completed, restart neutron

systemctl restart neutron-server

 

Start creating the new tenant networks and attaching the interfaces to your virtual firewall and other instances. Find out what port ID they have been assigned, this will be easy to locate using the GUI

 

 

Once you get the port ID execute the following to turn off port security

neutron port-update  2bf6b77b-627e-4fd0-8cd9-69dc0b27d65e --port-security-enabled=False

 

You can check to see if it too with the following command

neutron port-show 1ee02bbe-4f87-4cb4-91e0-ced0ef691e1c

 

Once completed on all interfaces required, that should resolve the routing issue.

 

Disabling port security will prevent you from using security groups. Firewalls don't really need security groups enabled but if you want more restriction you can use allowed address pairs instead.

 

neutron port-update 'Port UUID' --allowed_address_pairs list=true type=dict ip_address='ip or CIDR'

 

Apply this on all ports that will be use to route traffic.

 

Thursday, August 18, 2016

Setup DHCP client for SRX interface and port forwarding

Almost 3 years since I posted anything. Decided to make a quick post today since my firewall died and I replaced it with a Juniper SRX 210. For home use, this firewall kind of sucks. DHCP client on the WAN (untrusted) connection does not work out of the box, I had to do a little tweaking to get it running. In addition to that, the remote access VPN is clunky and I was unable to get it running using 3rd party client software. There is no UPnP of course, which is expected from this type of firewall. But like I said, I am using this as a temporary replacement cause my home firewall died so I had to manually open all my port which was kind of a pain.

 

First of all, to get my DHCP working so the ONT can assign my firewall an IP I had to do a couple of things. The first was enable the interface for DHCP client, that was easily done from the GUI with a check box. Next I execute the following from the shell

 

vi /etc/rc.custom

·         save this file

·         execute the following

sysctl -w net.inet.ip.mcast_ttl=64

·         Modify the permission

chmod 777 /cf/etc/rc.custom

 

 

Then from the CLI we need to modify the security policy to accept DHCP for the interface that needs to obtain an IP address. In my case it was the ge-0/0/0.0

 

 

set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcp

 

 

·         Then execute the following command

request system services dhcp renew ge-0/0/0.0

 

My firewall did not receive and IP address till I power cycled the ONT.

 

Enabling each port through the firewall was a serious beating. When using multiple ports to forward to the same server. You will need to make a new address entry for that same IP for each new rule. You can use and modify the following to make it a quick copy and paste

 

·         define your addresses

set security zones security-zone trust address-book address sodapc 192.168.150.99/32

·         define your applications

set applications application qbtor protocol tcp

set applications application qbtor destination-port 9497

·         define your nat rules

set security nat destination pool dnat-192_168_150_99m32 address 192.168.150.99/32

set security nat destination pool dnat-192_168_150_99m32 address port 9497

·         adjust the nat rule for your public IP

set security nat destination rule-set dst-nat rule rule3 match destination-address 0.0.0.0/0

set security nat destination rule-set dst-nat rule rule3 match destination-port 9497

set security nat destination rule-set dst-nat rule rule3 then destination-nat pool dnat-192_168_150_99m32

·         create the policies to permit the traffic

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match source-address any

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match destination-address sodapc

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match application qbtor

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 then permit

 

I have a ton of service at home so I went on with this for quite a while. UPnP would have saved a lot of time.

Thursday, October 31, 2013

Outbound Fax over ATA and VoIP failed

Recently I have been converting a lot of offices to VoIP. In addition to QoS & ACL there are other factors that could impact the phone line and quality of the call. One thing that particularly picky about how clean your phone line is FAX machines.

The location I was working on had Fiber network with awesome bandwidth. They had 8 Cisco ATA SPA122 adapters, 7 went into the phone system and 1 went to the fax machine. The ATA adapters were running the 1.21 firmware.

 

 

·         The problem they were experiencing was some faxes going out will fail.

·         No issues with incoming faxes at all.

·         Faxes that go out to fax machines connected to a POTS will succeed

·         Faxes that go out to some online fax services such as RingCentral, efax, etc will fail

·         The failure occurs despite the type of fax machine you use

·         You will hear the fax answer but it sounds like they fail to negotiate the type of protocol or something

 

Cisco’s 1.32 firmware sounded like they addressed the issue

CSCud58060  - ATA fails periodically while sending a v.34 fax in pass-through mode (Method=NSE) to a Cisco gateway.

 

But after contacting the VoIP vendor, they did not want to assist with upgrading the firmware. They were even hesitant with providing the admin password to the ATA (when ATA register to their SIP server, it changed the admin password).

Login into the ATA’s web interface as admin, if you plug in from the built in switch the default IP is 192.168.15.1. After logging in as admin you would need to go into Voice, click on Line 1, then scroll down to “Fax passthrough method” and set it to none.

 

Apply changes and this should fix any fax issues with other online fax services without updating your firmware.