Trending Topics

Implement and configure AWS Backup for VMware Cloud on AWS VM workloads

In our previous post we saw the design of the AWS Backup on VMC. In this post we’re going through the implementation steps As per the design and best practice, we are going to use the ENI for the Backup traffic CREATE A VPC ENDPOINT  TO CREATE AN INTERFACE ENDPOINT FOR AN AWS SERVICE 1. Open the Amazon VPC console at    2. In the navigation pane, choose Endpoints 3. Choose Create endpoint 4. Name the endpoint   5. For Service category, choose AWS services 6. For Service name, search “ Backup ” and select “ backup-gateway ” service from the dropdown 7. For VPC, select the VPC which we used for SDDC deployment and extension 8. To create an interface endpoint for Amazon S3, you must “uncheck” Additional settings, Enable DNS name. This is because Amazon S3 does not support private DNS for interface VPC endpoints 9. For  Subnets , select one subnet per Availability Zone which we used for SDDC VMC selection  10. For Security group , sel

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


AD LDS – Syncronizing AD LDS with Active Directory

DNS Scavenging.