I am not familiar with sails.js, nor am I a programmer, but I have been a task assigned to allow a secondary domain to access an existing sails app.
I currently see https://portal.firstdomain.com being served with the corresponding ssl key files setup in config/local.js.
My task would be to allow accessing the same application with https://portal.seconddomain.com. I already configured portal.seconddomain.com to point to the same IP address as portal.firstdomain.com. I am getting a page with a configuration error message. So I guess I am reaching sails.js. There is no other webserver active on this IP address. What is puzzling to me is that firstdomain.com is not mentioned anywhere in any configuration file. Except perhaps indirectly in the ssl files which are imported in config/local.js...
Where would I find the right documentation or hints which would explain to me what to do? Any hint is very appreciated.
Dan
Related
I used the Sophos UTM 9.510 ha_standalone Cloudformation template (https://github.com/sophos-iaas/aws-cf-templates/blob/master/utm/9.510/standalone.template) and used defaults when possible. I did not use an existing ElasticIP, so it created it's own at (scrubbed) 50.12.12.123.
I gave a hostname at (for example) vpn.example.com and after creation, I created an A record for vpn.example.com to point to 50.12.12.123.
I don't have a license and just pay hourly for the AMI.
I understand that I should be able to hit https://vpn.example.com:4444 or https://50.12.12.123:4444 to see the admin panel. However, it times out and doesn't load anything.
When I deployed the stack, I got an email at the admin email I provided and it said REST daemon not running - restarted. I assume it restarted fine, since I have received no new emails, and the EC2 instance is running.
Has anyone else experienced this? Is there a step I'm missing? Aside from creating the Route53 record, I thought the Cloudformation Template should just work right out of the box.
The default security groups blocked traffic. I modified one of them to accept all traffic and the dashboard became accessible. I will now refine access further.
I try to setup an OpenLDAP-Server that I can use as backend for a WebSSO (LemonLDAP::NG). This specific WebSSO allows to store the sessions inside the LDAP backend.
My problem is that it seems that whenever I connect to the LDAP backend to store session data ~1 out of 10 times it works, the other times LDAP rejects the authentication.
Logs for failed attempts and for successful attempts can be found here
As you can see the maker of LemonLDAP::NG thinks the error is within OpenLDAP (or my configuration of OpenLDAP). I'm out of ideas and open to suggestions.
Looks like someone changes OpenLDAP DB during your session. Don't you have any processes with access to MDB file except this instance of OpenLDAP?
It may be slapadd/slapmodify/2nd slapd instance with the same directory value in config.
If not, could you show your slapd.conf (don't forget to change rootpw)
I have previously configured firebase hosting successfully but now want to change the domain name I am using.
It appears you can Edit the current domain name but this doesnt seem to do anything that I can see when I enter a new domain name.
Not sure how to proceed.
Thanks,
Craig.
So I sent an email to firebase support and this process involves removing your current domain and adding a new domain which involves some downtime whilst they procure a new SSL certificate, etc.
If anyone is attempting to do this and does not want to incur any downtime its not too difficult. The highlevel process I have followed to move from olddomain.com to newdomain.com without downtime is detailed below:
Procure another temp server (i.e. amazon or whatever) and bring up nginx
Deploy your static files (css, js, html, jpg, etc) to this temporary server
Procure a cert for olddomain.com and deploy it on your server. You can get some free ones for a month if you have a search (dont want to endorse any particular product here)
Ensure the site is running as olddomain.com on your temp server (hack you hosts file to force your domain name to point at the new temp server.
If all good, modify your DNS for olddomain.com so it points at your temp server.
Wait a few hours to ensure all traffic going to your temp server (look at w3c style logs to ensure traffic is coming in)
You can now safely remove your olddomain.com and setup newdomain.com under firebase hosting without losing traffic to olddomain.com
Once newdomain.com setup and running on firebase hosting, configure olddomain.com to do a redirect to newdomain.com. May want to leave this up for a while depending upon how much traffic you are expecting to olddomain.com.
Job done without any downtime :)
Hope these steps are of use to others.
Thanks.
I created a new project with the desired domain name, then switched to the new project using the firebase use <project_id> command from Firebase CLI.
I've deployed in Windows Azure a website made with Umbraco, using
Windows Azure Accelerator for Umbraco.
For development and test i used a test Hostname. Now it's time to switch to the official DNS hostname..
How can I change current hostname?
Actually i configured hostname at deployment time (the only way i know to do this) but i can't deploy again, since many files have been changed working on website on Azure.
EDIT
Let me explain: at the step prompt in the image (during web site deploying) I used as Domain Name "test.mywebsite.com", and configured real DNS.
Now the website is configured, so I'd like to make mywebsite.com point to that site;
But is'nt enough if i configure mywebsite DNS! Shall I deploy again? An will I lose any of the changes I made?
I'd like to make two comments on your question:
1) In order to host your Azure application under a custom host name, you will need to sign up with a DNS provider that supports C-NAME records (most do). I suggest someone like GoDaddy.com because by default C-NAME records can only resolve your "www.domainname.com" records and cannot do anything for queries where "www." is dropped from the URL. DNS providers like GoDaddy also have an option to redirect all traffic destined for "domainname.com" to a URL of your choice. This is a huge deal for Azure apps. Frankly speaking, it is somewhat disappointing that for all the PaaS and IaaS features of Azure, DNS was not included in the overall package.
2) I am a little worried when you say that you can no longer redeploy your app due to the changes made. Can you elaborate on that? Have you made changes to the application's code running on VM's in Azure without going through redeployment process? If so, this is a huge no-no. Your VM's running in Azure are not "permanent". Microsoft and your redeployment process can (and will) re-stage those VM's to the original package at any given time. Microsoft will re-image your VM's at least once a month during their monthly OS upgrades. But they can also do so when they need to move your VM to another rack, etc. Whatever changes that you make to your app must be either stored in source-control before deployment or in a permanent storage facility like SQL Azure, Azure Storage, etc.
HTH
Finally i think that the answers to my questions are:
-Shall I deploy again? Yes, i must deploy again
-Will I lose any of the changes I made? Many changes will be mantained since are stored into DB. But I have to do many activities to make new website work!
This answer confirms my theory:
In my case, I created and uploaded a site with a name, let's say
http://www.contoso.com and then paid a domain from a registrar let's say
http://www.example.com, when I mapped
http://MyAcceleratorsService.cloudapp.net/ to my new domain
( http://www.example.com ) and tried to open that domain I got the home page of
the Accelerator and not the uploaded site.
I had to upload the site again to Azure (using UploadUmbracoSite.cmd
from Accelerator application) and when uploading enter the same domain
name as the one I registered: http://www.example.com. Then, I was able to
browse my uploaded site as expected.
As for your question, will upload site again using
UploadUmbracoSite.cmd (is in the Setup folder) and will enter the new
domain name when requested.
Exactly what I was trying to avoid.. but the only solution, i suppose.
Well it was not easy to publish again, i got errors of many type (i suppose tied to some components that i've installed after deploy and that are not installed in new deployed website).. i'm going to solve them.
Edit
Completed my work:
- loads of different attempts, no-one worked
- CTP backup of DB
- deleted DB and website
- new full deploy of umbraco
- CTP restore of DB
finally:
-all work on content is OK
-all work on styles, pages, templates is lost
Changing hostname is hard; dont'use test hostname but definitive hostname from the beginning.
If anyone has suggest, i'll be pleased to test it, anyway
This is not really an answer to your question, but it might be a solution to your problem: Use a CNAME record to make the production DNS name point to your development name. E.g. www.productionname.com will the point to www.testname.com. I am not sure if everything will just work out of the box, but it seems to be worth a try.
This requires, that your hosting provider allows you to set up CNAME records.
http://en.wikipedia.org/wiki/CNAME_record
I am currently trying to setup a redirect on write for an installation of OpenLdap 2.2.
I have two instances running. One is configured to be read-only (only read access, database specified as read-only) and has redirect configured to point to the second instance. The second instance is configured to allow for the desired write permissions.
When I attempt a modify on the first instance it fails as expected but does not send back the referral. Am I missing a piece of the configuration? Am I even on the right path? Any guidance would be greatly appreciated. Thanks.
In the database section of you slapd.conf do you add the redirection like this ? :
updateref "ldap://master-host:port/"
So, it turns out the best way to do this is to go ahead and set up replication using slurpd and point all requests at the slave instance. Unfortunately you can't set up the master and slave on the same host (for obvious reasons, but still), so I had to spin up a second VM to get this going.
Honestly, if I was not trying to replicate a redirect problem it wouldn't be worth it, but I have to duplicate a production issue.
For more information on slapd and specifically slurpd, the OpenLDAP documentation is actually crazy helpful: slurpd config for OpenLDAP 2.2