Trending Topics

VMware on AWS - How to restore NSX DFW firewall rules to previous state

Customers who uses NSX day-in, day-out would like to have a point-in time restore functionality of DFW firewall rules. Many customer have a large footprints in VMC and make changes to DFW quite often. This feature was missing for long time and we could see its included in recent versions . Let's see how DFW configuration roll back works  NSX DFW configuration has versioning, and it is stored in the NSX Manager.  Every time when someone update DFW configuration, NSX creates one more version but keep storing the previous ones. You can rollback for previous config but reapplying it once again.  You can find the options under Networking & Security tab , > Security > Distributed Firewall . In the right side we see an Actions drop down. Choose View to get to the below screen.  Let’s go through the use case:  1. Original state- default config with no custom rules:  a. There are no saved configurations during last 30 days: In my existing test setup, with the current setting

Building a new web server instance

These are the steps I took to create a new web server instance, which lives in AFS space and is based on uber . You should be able to follow these steps to create a new server instance. You'll need AFS administration access, kadmin access, the ability to create (or request) a DNS entry, and root access on every system you will be modifying.
These instructions apply to web servers that will host core services (things like myUMBC, spaces, webadmin, etc), which live under /afs/ If you're just looking to create a public web space for someone (/afs/,
  1. Request or create an IP address and DNS entry for the new server.
  2. Create an AFS volume to house the new server. Consult with an administrator to determine the server and partition to use. Use vos partinfo to see a list of available partitions with free space. Example:
3.  vos create -server -partition /vicepe -name admin.www.groups -maxquota 9000000
Then, mount the new volume at the root of the new server:
fs mkmount -dir /afs/ -vol admin.www.groups
If the web application you're deploying will have development and production instances, our convention is to create two separate volumes under a single directory in /afs/ Example:
mkdir /afs/
vos create -server -partition /vicepf -name -maxquota 9000000
fs mkmount -dir /afs/ -vol
vos create -server -partition /vicepf -name -maxquota 9000000
fs mkmount -dir /afs/ -vol
Then, create the dev and prod server instances under these mount points.
  1. Release the admin.www volume:
5.  vos release admin.www
  1. Add network interface to web server host. In this case, we are using www7 which is a zone within
7.  zones1# ifconfig bge0:14 plumb netmask broadcast zone up
8.  zones1# zonecfg -z
9.> add net> set physical=bge0> set address=> end> verify> commit> exit
It appears that this is all that is necessary for the new IP address to "stick" permanently with the zone.
  1. Create a Kerberos principal for the server instance:
18.kadmin: ank -randkey www/groups
19.kadmin: ktadd -k /tmp/www_groups.keytab www/groups
Put the keytab file in /etc/umbc on the web server host.
  1. Add an AFS user for server instance. Same as Kerberos principal except slash is replaced by a period.
21.pts createuser www.groups
  1. Set appropriate ACLs on server directory. The root MUST be readable by system:anyuser, so the startup script can find 'instance.conf'. /afs/
24.fs sa -acl webcore rlidwk -acl system:anyuser rl -acl www.groups rl -dir .
  1. Set up a local user on the web server host. Apache/etc will run as this user. By convention, the UID should match the AFS ID of the server instance principal. Run 'vipw' and add to /etc/passwd (note that the home directory need not exist):

And /etc/shadow:
Also note that with some servers, the password file entry is controlled by [cfengine]. However it appears that this practice was abandoned at a certain point..
Set ownership and permissions on the Kerberos keytab file: /etc/umbc
28.chown groupswww www_groups.keytab
29.chmod 400 www_groups.keytab
  1. create logging area (/var/umbc/groups) with correct permissions:
31.mkdir /var/umbc/groups
32.chown groupswww /var/umbc/groups
33.chmod 755 /var/umbc/groups
  1. Create web server hierarchy. /afs/
36.mkdir bin conf htdocs libexec logs bin
38.ln -s ../../uber/bin/init.d
IMPORTANT!!!! The server root must be world readable (system:anyuser) so the startup script can access 'instance.conf'. You may not want the entire web server tree world readable, though. In this case, go through now and remove system:anyuser access from the subdirectories you just created:
cd /afs/
fs sa -acl system:anyuser none -dir bin -dir conf -dir htdocs -dir libexec -dir logs
Additionally, the server instance will need write access to 'logs'..
fs sa -acl www.groups rlidwk -dir logs
You will also need to explicitly remove these permissions from any other top-level directories you create here, because they'll allow system:anyuser by default (based on server root's ACL).
  1. Create 'instance.conf' and 'httpd.conf'. For httpd.conf, it's typically easiest to steal a config file from another instance and strip it down.. Also, you might want to toss something into htdocs, just to prove that it works.
  2. Start up your new web server: /afs/
42../init.d start
Check log directory to make sure everything came up OK. Then try hitting it from a web browser.
  1. If you want the server to automatically start up and shut down with the server host, add appropriate links to init.d from /etc/rc0.d and /etc/rc2.d.
And that's it.. you should now have a working web server. Next, you might want to add SSL or Tomcat.

Cheers :)

Popular posts from this blog


DNS Scavenging.

AD LDS – Syncronizing AD LDS with Active Directory