User Controls
I know it's basic
-
2019-03-08 at 11:12 PM UTCmake this site niggasin.sex or i
m leaving -
2019-03-09 at 1:04 AM UTCWhat about 'www2'?
-
2019-03-09 at 1:09 AM UTC
-
2019-03-09 at 1:32 AM UTCThink of your SSN as your IP and your name is the domain. It doesn't matter what you change your name to, your SSN will always be the same. You can change your name from Mrs. Potato to to Mr. Potato and your SSN is still the same. The domain, the name, is just a label for the number.
-
2019-03-09 at 1:37 AM UTC
Originally posted by Lanny Same thing but like if you have two webservers for some reason (sometimes you see that for load balancing). Again, the subdomain doesn't actually mean anything, it's just a name you give to a host.
Didn't all this shit emerge before routes?
Before they'd be defined in hardware, which was also based on software, but had less crud associated with it.
Right not your ftp/www/whatever are all managed in software, by some software fag like Lanny. Even directories aren't even real any more, but are most likely defined in a wild abstraction layer, or even in a docker virtual environment or whatever the virtual machine above a virtual machine is.
Software load balancers as well. Cloud computing. You don't know what bullshit is going on. Don't feel bad, due to the way jobs are split out and layoffs conducted probably no one does. -
2019-03-09 at 10:17 AM UTC
Originally posted by MORALLY SUPERIOR BEING V: A Cat-Girl/Boy Under Every Bed Didn't all this shit emerge before routes?
Which shit? What do you mean by routes? Like multi-host routing? Because that's been a thing for a while.Before they'd be defined in hardware, which was also based on software, but had less crud associated with it.
Right not your ftp/www/whatever are all managed in software, by some software fag like Lanny. Even directories aren't even real any more, but are most likely defined in a wild abstraction layer, or even in a docker virtual environment or whatever the virtual machine above a virtual machine is.
FTP was never implemented in hardware lol, nor HTTP.Software load balancers as well. Cloud computing. You don't know what bullshit is going on. Don't feel bad, due to the way jobs are split out and layoffs conducted probably no one does.
Load balancers aren't really all that complex. I think a lot of people get intimidated by modern web "enterprise scale" stuff and just feel like it's black magic. But there's a pretty coherent logical thread to why modern large scale web architecture is what it is. -
2019-03-09 at 12 PM UTC
Originally posted by Lanny Which shit? What do you mean by routes? Like multi-host routing? Because that's been a thing for a while.
…
FTP was never implemented in hardware lol, nor HTTP.
Back in the day if you wanted to serve a file you had to either have it on disk or have a symlink to a file on disk.
For instance in ISS there is no usercp file, it's just generated dynamically by django and returned as if a html file exists at that location.
And if you wanted to run a ftp/whatever server on a particular domain you would have an actual machine with an ip address present, on, and usually dedicated exclusively to the task to do so, while now you are as likely as anything to just run a load of websites and services on one machine or cloud service and for instance serve by spinning up an instance as required, or based on http request headers or whatever. -
2019-03-09 at 10:37 PM UTC
Originally posted by MORALLY SUPERIOR BEING V: A Cat-Girl/Boy Under Every Bed Back in the day if you wanted to serve a file you had to either have it on disk or have a symlink to a file on disk.
There was an era where that was a popular mode of web hosting, but HTTP was never intended as a purely static resource transfer protocol. I mean even CGI is pretty dang old and it was just a standardization of a bunch of earlier ad-hoc ways of producing dynamic content.And if you wanted to run a ftp/whatever server on a particular domain you would have an actual machine with an ip address present, on, and usually dedicated exclusively to the task to do so, while now you are as likely as anything to just run a load of websites and services on one machine or cloud service and for instance serve by spinning up an instance as required, or based on http request headers or whatever.
I mean you still need servers to be on a particular IP address. Virtualization is a thing now but the point of that is that you can treat a virtual machine just like a physical one, from the programmer perspective it doesn't really complicate anything. -
2019-03-09 at 10:45 PM UTCWe actually had to work for it in our day.
-
2019-03-09 at 11:01 PM UTCHere's my current set up for my personal website (with essentially nothing up there yet, but I'm gradually going to be uploading various projects there over the next few weeks):
The URL is http://www.darrenmackenzie.com (or http://darrenmackenzie.com - both route to the same host).
I'm still working on properly configuring SSL certificates. AWS has a whole Certificate Manager service, and I think I somehow had it working at one point, but then fucked it up somehow later.
I actually registered the domain name with Google Domains for some reason (I was drunk and impatient and just grabbed it when I saw it was available, and didn't really think to register it on AWS where I host literally everything else online).
Then, I had to configure AWS Route 53 (a service for DNS routing). This part was actually suprisingly complicated (to me, at least). I thought it would be as simple as: 1. register a domain name, 2. somehow pair domain name to a live endpoint (such as the IP address or hostname for a physical machine hosting a web server, or a virtual machine hosting a web server). But, it turns out you have to actually specify the Name Server (the server that simply hosts the domain name), as well as the Canonical Name (CNAME), and set up TTL (timeout) settings, etc.
For virtual computing, I use AWS Elastic Beanstalk. It's basically a variable set of EC2 virtual machine instances that comes with load balancing features and automatic scaling options. It's actually pretty useful if you plan on hosting anything on the web that you expect any traffic towards.
On my Elastic Beanstalk virtual computers I host a simple Flask server that serves up template-based pages. The content that fills these templates at this current time are simply hosted on the same virtual machine as the Flask server (in subdirectories). This is, nowadays, pretty much an anti-pattern. I do plan on hosting all kinds of content/data on either AWS RDS (their relational database service), or MAYBE via a separated PostgreSQL service, and maybe even some data on a graph-based database service (Neo4J is pretty decent, and I have played around with it, but AWS, of course, has their own graph DB service - they have just about everything one could need, really).
There are so many different ways one can vary how they deploy, host, and scale their websites / web applications. Currently, that's how mine is set up. -
2019-03-09 at 11:14 PM UTC
Originally posted by Lanny There was an era where that was a popular mode of web hosting, but HTTP was never intended as a purely static resource transfer protocol. I mean even CGI is pretty dang old and it was just a standardization of a bunch of earlier ad-hoc ways of producing dynamic content.
People kinda forgot about http verbs and only used get and post until rest became big. -
2019-03-09 at 11:21 PM UTC
-
2019-03-11 at 5:40 AM UTC
Originally posted by gadzooks The URL is http://www.darrenmackenzie.com (or http://darrenmackenzie.com - both route to the same host).
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Mon, 11 Mar 2019 05:38:35 GMT
Server: Apache/2.4.37 (Amazon) mod_wsgi/3.5 Python/3.6.7
Content-Length: 5
Connection: Close
Hello -
2019-03-11 at 5:50 AM UTC
Originally posted by Admin HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Mon, 11 Mar 2019 05:38:35 GMT
Server: Apache/2.4.37 (Amazon) mod_wsgi/3.5 Python/3.6.7
Content-Length: 5
Connection: Close
Hello
Precisely.
I plan to build upon that foundation with all kinds of dope shit in the near future.
Stay tuned. -
2019-03-11 at 5:57 AM UTChttps://en.wikipedia.org/wiki/CNAME_record#Terminology_of_CNAME_vs_.22canonical_name.22
DNS CNAME records are specified in RFC 1034 and clarified in Section 10 of RFC 2181. CNAME records are handled specially in the domain name system, and have several restrictions on their use. When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. (If the resolver is specifically told to look for CNAME records, the canonical name (right-hand side) is returned, rather than restarting the query.) The canonical name that a CNAME record points to can be anywhere in the DNS, whether local or on a remote server in a different DNS zone.
For example, if there is a DNS zone as follows:
NAME TYPE VALUE
--------------------------------------------------
bar.example.com. CNAME foo.example.com.
foo.example.com. A 192.0.2.23
when an A record lookup for bar.example.com is carried out, the resolver will see a CNAME record and restart the checking at foo.example.com and will then return 192.0.2.23. -
2019-03-11 at 7:23 AM UTC
-
2019-03-11 at 9:38 AM UTC