Deploy a full app stack with a domain in under 5 mins.
Background Sometimes you just need a web app. Now! Whether for dev/test, a demo, or even a project where a “canned” app will suffice – nothing beats getting a full stack deployed for you in a matter of minutes. I needed a web-facing app for a demo, and decided to give Amazon Lightsail a try. It did not disappoint! Below is my experience (and the steps) for standing up a WordPress blog plus a domain registered with Amazon Route 53 service – all in under 5 minutes. Pre-requisites Amazon AWS subscription: I started with an existing subscription, if you have one -- follow along! Address/Email: For domain registration I used Amazon Route 53, but similar domain registration & configuration can be done with another registrar like GoDaddy. Part A: Get the domain We’ll start with buying the domain for our web app. In my case I decided to stand up a blog running WordPress, with the domain name: haxrip.net 1. Find the domain: use Route 53 to find the available domain(s) & add to cart. 2. Register the domain: complete registration with your address / email (used to verify the registrant contact info). 3. Verify email: click on the link in the verification email, and that should be it for domain registration. Mine returned as registered in just 3 minutes, your mileage may vary ;) Part B: Stand up the app stack While the domain is being registered we’ll create our WordPress deployment using Amazon Lightsail . Below are the minimum options to create the deployment. 4. Amazon Lightsail: find the Lightsail service in the AWS console (search by name/feature or under the “Compute” category). Click “Create Instance”. 5. Choose location, platform, blueprint: as with most other AWS services we need to pick the region where our resources will be deployed. Since we’re in Seattle, Oregon is the closest option. Next we’ll select Linux as the platform, and under “Apps + OS” I’ll select WordPress 5.3.0, which is the only available version at the time of the writing. 6. Choose instance plan & name: naturally we need to pay for the convenience of the cloud infrastructure, and the lowest priced plan will suffice. Finally, we’ll pick a fancy name for our deployment, and click “Create instance” at the bottom . That is it! 7. Get the IP: within seconds we see the deployment information (greyed out initially), which already contains the IP address assigned to our Linux instance. Everything should go live within a minute. 8. Check the site: it’s truly satisfying to be able to start working on our very own WordPress app within seconds of creating an instance. We can also “Connect using SSH” feature in the Lightsail portal or use our own SSH client to easily retrieve WordPress admin credentials. The good folks at Bitnami, who create and maintain app stacks automatically set up the username: “user” with a password that’s contained in a file “bitnami_application_password”, which we find in the root directory of our instance. Part C: Update domain 9. Create domain record: once we have the IP address of our Lightsail instance, we can update the domain’s A-record with this IP. We’ll need to edit the hosted zone for our domain (pick the one you’ve registered), and click “Create Record Set”. Next, we choose Type: “A – IPv4 address” and enter the IP of our instance. We’re using TTL (time to live) value of 60, but you may want to choose what’s right for you. Click “Create”, and we are done! 10. Enjoy! Conclusion Cloud makes it easy to stand up a full app stack with a domain. While there are many other ways to deploy a full stack, Amazon Lightsail and Amazon Route 53 make it super easy. In my case, I was able to kick off a registration of a domain, stand up an Amazon Lightsail instance and log into my WordPress site - all in ~3 minutes. By the time I updated my domain’s zone with a new record, my domain registration had completed. The entire thing was up and running with a domain in under 5 minutes. That’s cloud speed!
Multiple SAML SP access profile MRH cookie issue
Dear all, I am trying to configure the F5 Big IP as both SP and IDP using seperate access profiles configured on scope level profile (isolated). The IDP will then assure the SSO across all the SP applications, this is already working in version 15.1.3 but in version 16.0/16.1 the MRH cookie behavior seems to have changed. All SP share the same parent domain, the difference between 15.1 and 16 is the following: In version 15.1 for each domain name a specific cookie is created and F5 does not include the domain option in the response, on the clientside we see specific cookie entries for the complete domain with the respective MRH cookie. when connection to /my.policy the F5 responds with the MRH session cookie witout domain so the browser saves it as the specific host name / domain. In version 16 APM is responding with a wildcard domain *.example.com this results in issues when connection to the same domain for example idp.example.com the client sends the old MRH cookie and APM session are restarted/deleted. Is there a fix so that the per specific domain can be maintained when using SAML auth in access profiles? Perhaps an Irule that will remove the domain in response?
Spilt DNS resolution for Dev and Prod domains in APM (portal access)
Hi All I have an issue where a client has a DEV environment and a Production environment, both using the same Domain Space. They have an issue when using APM Portal resources and DNS lookups. Basically they have 2 VIPs set up, one for Dev and one for production but the issue occurs when the F5 needs to do a lookup for the portal resources. The F5 can be configured with multiple DNS servers but the device will always query one DNS server (most likely the first one) for a DNS resolution, and cant distinguish if it should return a DEV address or a portal address. The long and short is that when a client accesses the dev VIP i want any DNS requests to go to the DEV DNS servers and all other DNS requests go to the Prod DNS servers. I tried looking down the route of configuring a DNS VIP and pointing the F5's DNS servers at that, but all the requests are coming from the F5 so we can't make a decision based on client source address, and all the DNS requests are the same URL/domain so we cant make decisions on that either! They dont have GTM but im not sure that would help in this situation either. Any help or suggestions would be greatly appreciated. Regards Phil
iRule to secure flag on specific URL (Multiple URL in one VS)
Hi We know that F5 can add secure attr in cookie from irule HTTP_RESPONSE <https://support.f5.com/csp/article/K11324> but this is apply to all website in virtual server!! We have many URL in one virtual server. (Multi domain). ie URL-a.example.com and URL-b.example.com have the same Virtual server Can we just add secure flag on cookie only when we access URL-a.example.com ? no need to add flag when we access URL-b I think we need variable to check if http:host is URL-a or URL-b, but I don't know how to do it when this variable has to share on HTTP_REQUEST and HTTP_RESPONSE event on the same times. Thank you
taking value and append to uri while masking?
Hello F5 community: Is there such a way to create an irule which will take the value before the domain, *.test123.com, append it to ) and pull up the contents without changing the URL in the browser? for example. A user types in help.test123.com in the browser, but it will pull up the site contents from without changing the URL in the browser.APM SSO for different domain joined machines?
I have a scenario and I THINK it may be caused by below issue. I have an app, let's call it MYAPP, which is integrated with F5 APM for SSO using basic/kerberos auth. THe F5 is setup to use a specific domain, let's call it mydomain.com. A machine that is either domain joined to mydomain.com can login to my application fine using 3 major browsers (IE, Chrome and Firefox). When the machine is NOT domain joined, browser will prompt for credentials in all 3 browsers, then log user in fine. What I have noticed is that if a user tries to login using a machine that is joined to a DIFFERENT domain, in Internet Explorer/Chrome, the user will receive the login prompt (as kerberos should fail) but APM denies them access even when they type their username as "mydomain\user". The only exception is Firefox, which allows the user to enter their credentials and still sign in. My question is: 1. Why does this occur? 2. What is the fix? Is there an F5 side fix? Is there a client side fix? Thanks all!!
Domain was fixed in Internet Security on Internet Explorer (IE)
How it possible to edit the domain in Internet Security when it's prompt as this image below example image I has set the F5 APM to fixed the domain name, using Variable Resource Assign expr { "[mcget {session.ad.last.actualdomain}]\\[mcget {session.logon.last.username}]" } I try with Chrome, Firefox so it's work well, but in IE have fixed the Domain for each PC. For my guess, I think the behavior of Chrome and Firefox will be like Username : username Password : password after we input the information above the Variable Resource Assign will automatically add the domain to be the domain\username . On the other hand, the result of IE (that browser fix domain) will be like RINGWORLD\domain\username that will make authentication abort. My idea is to check the browser type, if the client use IE -> the F5 APM will remove the domain that fixed from the browser. Finally, I am not sure that it's possible to do it like this way or someone can give me a better solution. -F5 APM with Version 12.1.2 HF1 -IE Version 11 -F5 SSL VPN Thank you very much
