Trending Topics

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

Image
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 https://console.aws.amazon.com/vpc    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/umbc.edu/admin/www. If you're just looking to create a public web space for someone (/afs/umbc.edu/public/www),
  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 bfs1.afs.umbc.edu -partition /vicepe -name admin.www.groups -maxquota 9000000
Then, mount the new volume at the root of the new server:
fs mkmount -dir /afs/.umbc.edu/admin/www/groups -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/umbc.edu/admin/www. Example:
mkdir /afs/.umbc.edu/admin/www/rt
vos create -server bfs1.afs.umbc.edu -partition /vicepf -name admin.www.rt.dev -maxquota 9000000
fs mkmount -dir /afs/.umbc.edu/admin/www/rt/dev -vol admin.www.rt.dev
vos create -server bfs1.afs.umbc.edu -partition /vicepf -name admin.www.rt.prod -maxquota 9000000
fs mkmount -dir /afs/.umbc.edu/admin/www/rt/prod -vol admin.www.rt.prod
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 zones1.core.umbc.edu..
7.  zones1# ifconfig bge0:14 130.85.24.131 plumb netmask 255.255.255.0 broadcast 130.85.24.255 zone www7.umbc.edu up
8.  zones1# zonecfg -z www7.umbc.edu
9.  zonecfg:www7.umbc.edu> add net
10.zonecfg:www7.umbc.edu:net> set physical=bge0
11.zonecfg:www7.umbc.edu:net> set address=130.85.24.131
12.zonecfg:www7.umbc.edu:net> end
13.zonecfg:www7.umbc.edu> verify
14.zonecfg:www7.umbc.edu> commit
15.zonecfg:www7.umbc.edu> 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:
17.kadmin
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'.
23.cd /afs/umbc.edu/admin/www/groups
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):

26.groupswww:x:105459:1::/home/groupswww:/bin/sh
And /etc/shadow:
groupswww:*LK*:::::::
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:
27.cd /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.
35.cd /afs/umbc.edu/admin/www/groups
36.mkdir bin conf htdocs libexec logs
37.cd 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/umbc.edu/admin/www/groups
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:
41.cd /afs/umbc.edu/admin/www/groups/bin
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

HOW TO EDIT THE BCD REGISTRY FILE

AD LDS – Syncronizing AD LDS with Active Directory

DNS Scavenging.