I think it's important that our domain name matches our project name.
yep. i will copy the vhosts and work out how to transfer the domain without losing google page rank veera could i ask you the favour of looking up how to do that, for nginx? what we want is to keep absolutely every single page that has gone into google search, but get search engines to migrate to the new domain over time. it will probably be a 302 redirect or something.
* whois done. * dns done * exim4 done
Luke, sure I will lookup about how to keep google search engine ranking.
(In reply to vklr@vkten.in from comment #3) > Luke, sure I will lookup about how to keep google search engine ranking. thanks appreciated
Both HTTP 301 and 302 redirects work. They both save Google Pagerank <link https://support.google.com/webmasters/answer/6033049?hl=en>. But it is better to use 301 permanent redirect.
Relevant difference between HTTP Permanent 301 and Temporary 302 redirects. <link https://stackoverflow.com/questions/1393280/http-redirect-301-permanent-vs-302-temporary>
In Nginx http redirects can be done with three directives 1) return Faster; no regexp processing done 2) rewrite Slower; regexp processing done 3) try_files Slower; disk hog Example with return directive server { listen 80; listen 443 ssl; server_name libre-riscv.org; return 301 http://libre-soc.org$request_uri; return 301 https://libre-soc.org$request_uri; } Example with rewrite directive server { listen 80; listen 443 ssl; server_name libre-riscv.org; rewrite ^ http://libre-soc.org$request_uri permanent; rewrite ^ https://libre-soc.org$request_uri permanent; } <link https://www.nginx.com/blog/creating-nginx-rewrite-rules/> Note, I have not tested this on a real nginx setup. If more help is needed please inform.
ahh excellent, thank you veera.
We still need to set up the correct HTTPS certificates, nearly everything (including libre-soc.org) still defaults to git.libre-riscv.org's cert.
(In reply to Jacob Lifshay from comment #9) > We still need to set up the correct HTTPS certificates, nearly everything > (including libre-soc.org) still defaults to git.libre-riscv.org's cert. Using self-signed certificates is very easy with nginx. Is anyone thinking of using Let's Encrypt Certificates. There are acme clients to do it. Some based on python, the official one. With the most functionality. Some based on shell scripts; very simple and easy to setup and use.
(In reply to vklr@vkten.in from comment #10) > (In reply to Jacob Lifshay from comment #9) > > We still need to set up the correct HTTPS certificates, nearly everything > > (including libre-soc.org) still defaults to git.libre-riscv.org's cert. > > Using self-signed certificates is very easy with nginx. > > Is anyone thinking of using Let's Encrypt Certificates. > There are acme clients to do it. > Some based on python, the official one. With the most functionality. > Some based on shell scripts; very simple and easy to setup and use. It might be a good idea to use a wildcard certificate that works for both *.libre-riscv.org and *.libre-soc.org, that way, you won't have to configure a different certificate for each part of the website. I've been doing that on my personal webserver using Let's Encrypt and certbot and it works quite well.
Self-signed Certificates have the possibility of Man in the Middle Attacks, if we do not do proper certificate verification in user side. Like checking certificate hash signature(fingerprints). While Let's Encrypt certificates have certification from root authorities. It is to be noted their certificates are valid only for 90 days. They have to be periodically renewed using acme clients; either manually or automatically using cron.
err i haven't actually set up the vhosts at all yet!
(In reply to vklr@vkten.in from comment #12) > Self-signed Certificates have the possibility of Man in the Middle Attacks, > if we do not do proper certificate verification in user side. Like checking > certificate hash signature(fingerprints). They also have the other major drawback of not being trusted by default by web browsers. > While Let's Encrypt certificates have certification from root authorities. > It is to be noted their certificates are valid only for 90 days. They have > to be periodically renewed using acme clients; either manually or > automatically > using cron. We're currently using Let's Encrypt certs. One drawback of using wildcard certificates is that requires using the DNS-01 challenge which requires programmatically/manually modifying a DNS TXT record to verify ownership of the domains. For my personal website, that actually works out better since I don't have my server publicly accessible (home internet & no public IP addresses), I can still generate https certs by manually modifying the DNS records, which don't require my server to have a public IP address.
(In reply to Jacob Lifshay from comment #14) > (In reply to vklr@vkten.in from comment #12) > > Self-signed Certificates have the possibility of Man in the Middle Attacks, > > if we do not do proper certificate verification in user side. Like checking > > certificate hash signature(fingerprints). > > They also have the other major drawback of not being trusted by default by > web browsers. > Web browsers are also user side! > We're currently using Let's Encrypt certs. One drawback of using wildcard > certificates is that requires using the DNS-01 challenge which requires > programmatically/manually modifying a DNS TXT record to verify ownership of > the domains. > > For my personal website, that actually works out better since I don't have > my server publicly accessible (home internet & no public IP addresses), I > can still generate https certs by manually modifying the DNS records, which > don't require my server to have a public IP address. We can use Acme Http challenge to issue certificates for main as well as it's specific subdomains if we do not want wildcard certificates.
wildcard works well. i really do not want the hassle of setting up five or more separate ssl cerificates: git list smtp main ftp bugs and more in the future.
(In reply to Luke Kenneth Casson Leighton from comment #16) > wildcard works well. i really do not want the hassle of setting up five or > more separate ssl cerificates: git list smtp main ftp bugs and more in the > future. There is a misunderstanding. Wildcard certificates support only one level of sub-domains. E.g. *.example.com and not a.b.example.com Wildcard certificates is deprecated by a RFC because of security risk. Certificates have a thing called SAN (Subject Alternative Name). Multiple SAN's can be specified for a single certificate. Which allows many subdomains to be specified in a single certificate. E.g. example.com, a.example.com, b.example.com, m.a.example.com, t.b.example.com Let's Encrypt certbot acme client allows http challenge for this multiple SAN type setup. But wildcard certificate creation can be done with dns challenge only.
ah ok thank you. i don't think we will go the 4 level subdomain route.
(In reply to vklr@vkten.in from comment #17) > Certificates have a thing called SAN (Subject Alternative Name). > Multiple SAN's can be specified for a single certificate. > Which allows many subdomains to be specified in a single certificate. > E.g. example.com, a.example.com, b.example.com, m.a.example.com, > t.b.example.com Assuming SAN works cross-domain, we should use the same cert for both libre-soc.org and libre-riscv.org as well as their subdomains since they're all on the same server.
(In reply to Jacob Lifshay from comment #19) > (In reply to vklr@vkten.in from comment #17) > > Certificates have a thing called SAN (Subject Alternative Name). > > Multiple SAN's can be specified for a single certificate. > > Which allows many subdomains to be specified in a single certificate. > > E.g. example.com, a.example.com, b.example.com, m.a.example.com, > > t.b.example.com > > Assuming SAN works cross-domain, we should use the same cert for both > libre-soc.org and libre-riscv.org as well as their subdomains since they're > all on the same server. Yes. SANS works cross-domain. But if we need to add a new subdomain to the certificate, a new certificate has to be made. We have to apply the new one to all services which require a TLS/SSL Certificate. If automated it is hassle free. There is a nginx plugin but it is not safe. Webroot plugin is safer. It generates a certificate in a directory, and we have to copy it to required final place. In certbot example, it needs a two web root directories for two base cross-domains but not needed for subdomains. So we need to setup at least 2 vhosts in nginx; one for libre-soc and one for libre-riscv.org. There are also limits on renewals. <link https://certbot.eff.org/docs/using.html> <link https://letsencrypt.org/docs/rate-limits/>
(In reply to vklr@vkten.in from comment #20) > There is a nginx plugin but it is not safe. Webroot plugin is safer. It > generates a certificate in a directory, and we have to copy it to required > final place. The way I did it was just making symlinks to the location that certbot stores the latest version of the certificate (it stores it in a subdirectory of /etc/letsencrypt with access only allowed by root). That way, no copying is needed, all that's needed is to have the appropriate programs reload the certificates. > In certbot example, it needs a two web root directories for two > base cross-domains but not needed for subdomains. So we need to setup at > least > 2 vhosts in nginx; one for libre-soc and one for libre-riscv.org. > There are also limits on renewals. The rate limit is high enough that as long as we're not doing dumb stuff we shouldn't ever hit it.
(In reply to Jacob Lifshay from comment #21) > (In reply to vklr@vkten.in from comment #20) > > There is a nginx plugin but it is not safe. Webroot plugin is safer. It > > generates a certificate in a directory, and we have to copy it to required > > final place. > > The way I did it was just making symlinks to the location that certbot > stores the latest version of the certificate (it stores it in a subdirectory > of /etc/letsencrypt with access only allowed by root). That way, no copying > is needed, all that's needed is to have the appropriate programs reload the > certificates. Certificates should not be shared to all, but only to specific programs we want to. They are kept in root accessible area for security measure. But programs should not be allowed to run as root or have access to root accessible area. Usually for isolating, programs are run in separate UID and GID. So they cannot access only root accessibly dirs. It may be better to make separate Unix Group and User for certificate distribution purpose. Make a directory with that group and user. Copy the private key and public certificates from /etc/letsencrypt/... to it. Make the directory group permissions rx. Put the necessary programs/daemons process user to this Group.
I went to libre-soc.org and it's set to what looks like a default website -- totally unrelated (except for the references to lkcl) to Libre-SOC. I think we should at least set up a simple landing page stating that construction is in progress and linking to libre-riscv.org and this bug report, since it shouldn't take very long and it's at least better than what's there now.
this needs the website (nginx), exim4, bugtracker, git repos, etc. all duplicated for libre-soc.org *before* setting up the "redirector". exim4 "management" (redirectors) is done via files in /etc/exim4/virtual
Exim config: libre-soc.org added - prov ought to leave libre-riscv.org Bugzilla config: changed to libre-soc.org
I think that all is now done.