Managing Firewalls for EODN Depots
1. How to manage the firewalls for EODN Depots?
IBP Server communicates on tcp port 6714 and must be able to receive traffic on that port. In most campus environments, this means that a hole must be opened in the campus firewall allowing incoming traffic on tcp 6714 to the depots IP. In most cases, a request to your campus networking department will be required.
As an additional security measure, the depot itself can be configured to allow only necessary incoming traffic. This script will lock down a CentOS box so that only ports 22 (ssh) and 6714 (IBP) are allowed in. This is suitable for a system that will be serving only as an IBP server. If other functionality is needed (such as http web access) additional ports will need to be opened. This example uses vi or vim. Another text editor can be substituted.
1. Log in to the IBP server as root or with an account with sudo privileges
2. Create a new vi session:
| [my host] $ vi firewall_rules |
3. put vi into “ insert mode”
| i |
4. copy and paste the following code into the file
|
# ************* start *************** # iptables default configuration script # # set defalt action to accept for INPUT chain iptables -P INPUT ACCEPT # # Flush all current rules from iptables # iptables -F # # Allow SSH connections on tcp port 22 # This is essential when working on remote servers via SSH to prevent locking yourself out of the system # iptables -A INPUT -p tcp --dport 22 -j ACCEPT # # Accept IPB protocol packets # iptables -A INPUT -p tcp --dport 6714 -j ACCEPT # # Set default policies for INPUT, FORWARD and OUTPUT chains # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Set access for localhost # iptables -A INPUT -i lo -j ACCEPT # # Accept packets belonging to established and related connections # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # # Save settings # /sbin/service iptables save # # List rules # iptables -L -v # ****************** end ****************** |
5. Save and quit
|
<esc>:wq |
6. Make the file executable
|
[my host]# chmod 777 firewall_rules |
7. Run the script as root
|
[my host] $ sudo ./firewall_rules or, if you are logged in as root [my host]# ./firewall_rules****** setting up iptables for a dedicated ibp depot ****** |
This script will lock down a CentOS box so that only ports 22 (ssh) and 6714 (IBP) are allowed in. This is suitable for a system that will be serving only as an IBP server. If other functionality is needed (such as http web access) additional ports will need to be opened. This example uses vi or vim. Another text editor can be substituted.
1. Log in to the IBP server as root or with an account with sudo privileges
2. Create a new vi session:
|
[my host] $ vi firewall_rules |
3. put vi into “ insert mode”
| i |
4. copy and paste the following code into the file
|
# ************* start *************** # iptables default configuration script # # set defalt action to accept for INPUT chain iptables -P INPUT ACCEPT # # Flush all current rules from iptables # iptables -F # # Allow SSH connections on tcp port 22 # This is essential when working on remote servers via SSH to prevent locking yourself out of the system # iptables -A INPUT -p tcp --dport 22 -j ACCEPT # # Accept IPB protocol packets # iptables -A INPUT -p tcp --dport 6714 -j ACCEPT # # Set default policies for INPUT, FORWARD and OUTPUT chains # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Set access for localhost # iptables -A INPUT -i lo -j ACCEPT # # Accept packets belonging to established and related connections # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # # Save settings # /sbin/service iptables save # # List rules # iptables -L -v # ****************** end ****************** |
5. Save and quit
|
<esc>:wq |
6. Make the file executable
|
[my host]# chmod 777 firewall_rules |
7. Run the script as root
|
[my host] $ sudo ./firewall_rules or, if you are logged in as root [my host]# ./firewall_rules |
Manually Configuring EODN Storage Resources
1. How to manually configure EODN Storage Resources?
Introduction
The DLT installer has the capability to create an initial storage resource for the depot. However, this automated capability is limited. If you want to configure specific storage locations or multiple storage resources, it is necessary to do so manually. This document is a streamlined guide creating IBP storage resources and adding them to the IBP configuration file. For a full discussion of IBP storage configuration, please refer to the IBP Configuration Guide at https://github.com/datalogistics/ibp_server/blob/master/README
Background
The Data Logistics Toolkit (DLT) used to install EODN depots actually installs an Internet Backbone Protocol (IBP) depot. What makes an IBP depot an EODN depot is simply registering it with EODN. IBP depot storage resources consist of two things, a database of allocations representing the data stored on the depot and the actual storage. A directory structure for both of these must be created within storage attached to the IBP depot.
An IBP storage resource can be any block device addressable by the depot: a portion of the main system drive, a separately mounted disk drive, a mounted RAID strip, a Logical Volume, or even a mounted flash drive. The associated database can be stored in a directory on the storage volume itself, or on any other location accessible by the depot. Often the databases for multiple storage resources are stored together on the system drive.
Information defining each storage resource is stored along with other depot configuration details in /etc/ibp.cfg. A separate resource block identified by [resource <id>] exists in ibp.cfg for each storage resource.
Creating new storage resources
New storage resources are created with the mkfs.resource command. This command creates the directory structures for the database and storage, and returns the code needed to add the resource to ibp.cfg.
The syntax is as follows:
|
[myhost] # ./mkfs.resource <IBP id (unique)> dir <path to drive> <path to drive DB> <-b maximum size in MB> <-d maximum duration for allocation in seconds> Where: |
The results of this command must be copied into ibp.cfg to define the resource.
For example, say you have two disk drives mounted as /ibp_store/d1 and /ibp_store/d2, and you wish to allocate all of the storage on these volumes as EODN storage. Further, you have elected to store all the IBP databases under /opt/ibp_db. Issue this command to create ibp storage resource 101:
|
[myhost] # mkfs.resource 101 dir /ibp_store/d1 /opt/ibp_db/d1 The following is returned by the process:
[resource 101] rid = 101 max_duration = 5529600 resource_type = dir device = /ibp_store/d1 update_alloc = 1 mode = read,write,manage enable_read_history = 1 enable_write_history = 1 enable_manage_history = 1 enable_alias_history = 1 cleanup_interval = 600 rescan_interval = 86400 delete_grace_period = 7200 expire_grace_period = 1209600 preexpire_grace_period = 86400 max_size = 3952 soft_size = 3952 hard_size = 3952 minfree_size = 10240 preallocate = 0 enable_chksum = 1 chksum_type = MD5 chksum_blocksize_kb = 64 n_cache = 100000 cache_expire = 30
[db 1] loc = /opt/ibp_db/d101 #soft_used = 0 mb #hard_used = 0 mb #soft_used = 0 b #hard_used = 0 b #n_allocations = 0 #n_alias = 0 Use the same command to create storage resource 102: [myhost] # mkfs.resource 1022 dir /ibp_store/d2 /opt/ibp_db/d2 Producing: [resource 102] rid = 102 max_duration = 5529600 resource_type = dir device = /ibp_store/d=2 update_alloc = 1 mode = read,write,manage enable_read_history = 1 enable_write_history = 1 enable_manage_history = 1 enable_alias_history = 1 cleanup_interval = 600 rescan_interval = 86400 delete_grace_period = 7200 expire_grace_period = 1209600 preexpire_grace_period = 86400 max_size = 3952 soft_size = 3952 hard_size = 3952 minfree_size = 10240 preallocate = 0 enable_chksum = 1 chksum_type = MD5 chksum_blocksize_kb = 64 n_cache = 100000 cache_expire = 30
[db 102] loc = /opt/ibp_db/d102 #soft_used = 0 mb #hard_used = 0 mb #soft_used = 0 b #hard_used = 0 b #n_allocations = 0 #n_alias = 0 |
Now copy both sets of results into the ibp.cfg file producing something like this:
|
[myhost] # more /etc/ibp.cfg # Do not modify this directly. It will lose changes after service restart. # Change in ibp_configure.py and then do 'service ibp-server restart' [server] interfaces=192.70.161.60:6714; lazy_allocate=1 threads=16 log_file=/var/log/ibp_server.log password=ibp big_alloc_enable=1 substitute_map=
[phoebus] file://localhost/message/%253C33608345.11923427@walmart.com%253E
[resource 101] rid = 101 max_duration = 5529600 resource_type = dir device = /ibp_store/d1 update_alloc = 1 mode = read,write,manage enable_read_history = 1 enable_write_history = 1 enable_manage_history = 1 enable_alias_history = 1 cleanup_interval = 600 rescan_interval = 86400 delete_grace_period = 7200 expire_grace_period = 1209600 preexpire_grace_period = 86400 max_size = 3952 soft_size = 3952 hard_size = 3952 minfree_size = 10240 preallocate = 0 enable_chksum = 1 chksum_type = MD5 chksum_blocksize_kb = 64 n_cache = 100000 cache_expire = 30 [db 1] loc = /opt/ibp_db/d101 #soft_used = 0 mb #hard_used = 0 mb #soft_used = 0 b #hard_used = 0 b #n_allocations = 0 #n_alias = 0
[resource 102] rid = 102 max_duration = 5529600 resource_type = dir device = /ibp_store/d=2 update_alloc = 1 mode = read,write,manage enable_read_history = 1 enable_write_history = 1 enable_manage_history = 1 enable_alias_history = 1 cleanup_interval = 600 rescan_interval = 86400 delete_grace_period = 7200 expire_grace_period = 1209600 preexpire_grace_period = 86400 max_size = 3952 soft_size = 3952 hard_size = 3952 minfree_size = 10240 preallocate = 0 enable_chksum = 1 chksum_type = MD5 chksum_blocksize_kb = 64 n_cache = 100000 cache_expire = 30
[db 102] loc = /opt/ibp_db/d102 #soft_used = 0 mb #hard_used = 0 mb #soft_used = 0 b #hard_used = 0 b #n_allocations = 0 #n_alias = 0[resource 102] rid = 102 max_duration = 5529600 resource_type = dir device = /ibp_store/d=2 update_alloc = 1 mode = read,write,manage enable_read_history = 1 enable_write_history = 1 enable_manage_history = 1 enable_alias_history = 1 cleanup_interval = 600 rescan_interval = 86400 delete_grace_period = 7200 expire_grace_period = 1209600 preexpire_grace_period = 86400 max_size = 3952 soft_size = 3952 hard_size = 3952 minfree_size = 10240 preallocate = 0 enable_chksum = 1 chksum_type = MD5 chksum_blocksize_kb = 64 n_cache = 100000 cache_expire = 30
[db 102] loc = /opt/ibp_db/d102 #soft_used = 0 mb #hard_used = 0 mb #soft_used = 0 b #hard_used = 0 b #n_allocations = 0 #n_alias = 0
[unis] name = IBP Server type = ibp_server endpoint = https://dlt.crest.iu.edu:9000 protocol_name= ibp registration_interval = 600 publicip = 192.70.161.60 publicport = 6714 use_ssl = 1 client_certfile = /usr/local/etc/dlt-client.pem client_keyfile = /usr/local/etc/dlt-client.key institution = SFASU country = US state = TX zipcode = 75962 email = prblackwell@sbcglobal.net latitude = 31.6221 longitude = -94.6474 |
Restart the depot and the new storage will be available:
|
[myhost] # service ibp-server restart |
UCS Appliance FAQs
1. How do I order the appliance?
Contact Chad Teets, at CompuCom (chad.teets@compucom.com) or Rich Seidner at Cisco (ricseidn@cisco.com) and one of them can forward you with step by step instructions on how to place an order (See CompuCom fulfillment steps).
2. Is CompuCom the only Cisco Value Added Reseller (VAR) able to participate in this offering?
Yes, Cisco, Internet2 and DLT worked closely with CompuCom to develop a turn-key fulfillment solution that includes detailed procurement and fulfillment.
3. Will this solution work on a blade server?
Cisco, Internet2 and DLT initially selected a rack server to simplify the solution and to enable non-IT resources the ability to deploy the solution with little to no technical support.
4. Is this a fixed configuration or can I select a different CPU and/or amounts of memory?
Once again, in order to simplify the process Cisco, Internet2 and DLT worked closely to develop the best configuration to maximize price and performance, with an emphasis on ease of deployment.
5. How long will it take to receive my server?
Standard lead time for the server is three to four weeks.
6. Who do I contact if I have an issue installing the server?
Your first call should be to CompuCom Engineering Help Desk at 1-800-NXX-XXXX and they will assist with your questions and/or escalate to Cisco, SanDisk and/or DLT if they cannot remedy the issue.
7. Are there other universities that have deployed this solution?
Cisco and DLT anticipate that other universities and research institutions will deploy the appliance, and with the proper approvals, we will share this data with interested parties. In the meantime, the initial deployment will be at Industry/University Cooperative Research Center (I/UCRC).
8. What if my application requires more storage?
Cisco, Internet2 and DLT are currently working to certify a complimentary Cisco UCS invicta Series Solid State System to provide additional storage resources than those contained in the BOM.
9. Is the Bill of Material (BOM) available for review?
Yes, CompuCom can provide you with a BOM if needed. Contact Chad Teets at chad.teets@compucom.com
10. What applications are best suited for this appliance?
Cisco and Internet2 are working to publish a list of applications that are best suited for this appliance. A blog is being considered so universities can socialize and share their experiences and best practices.
11. Who should I contact if I need more information about the OS and/or the pre-installed “Executable”?
Contact DLT if you have any questions about which OS versions are supported and/or have questions about the “Executable”.
12. What about maintenance on the hardware and software?
The price of the appliance includes three year Cisco SMARTnet support (8x5xNBD) on both the hardware and software. Please see the following link for details on Cisco SMARTnet Services;
http://www.cisco.com/en/US/services/ps2827/ps2978/services_at_a_glance_smartnet.pdf
