connecting to a linux server

[skaterdav85]

So at work I have been told that a virtual server has been created for my web app. It's Linux, but I'm not sure how to connect to it. I've been told I need to connect to it remotely, but I haven't dealt with Linux much and was hoping anyone here can provide any advice to get me started!

[boen_robot]

Connect to it remotely how? The ways to connect to it vary greatly depending on the kind of server they've set up.If it's SFTP or SCP, it's easiest if you use WinSCP. If it's SSH or Telnet, you can use PuTTY. If it's another way... well... say what it is first.

[skaterdav85]

They say it is a VM server, which stands for Virtual Machine i think. All they gave me was the server name, IP, OS, and root password. In the past i have never had to set up a server because i just buy hosting and they have ftp servers so it is much easier to move my application into production.

[boen_robot]

It would probably be best if you ask them how to connect then. It will be cruel of them if using the exact OS and it's remote connection utility is the only way to connect and manage the server (if it's "the best" way, that's another story, but if it's the only, it speaks bad of them).

[justsomeguy]

Have you tried connecting via FTP or SSH? What about HTTP?

[skaterdav85]

haha ok. i've been told i need to SSH. That sounds like a pain in the butt doing everything from the command line...Also, another question related to servers, what is the difference between an FTP server and a web server? Are they typically the same machine? I know web servers serve our files to browsers and i use an ftp client to move my files to an ftp server, but i was never really clear on how an ftp server and web server relate and interact.

[skaterdav85]

Have you tried connecting via FTP or SSH? What about HTTP?

im trying ssh through putty, but im not quite sure what the port is

[boen_robot]

The port, the SSH password (if you haven't set it yourself), the key file (if any; there should be; if not, there should be instructions to generating it) are all details your host should reveal to you.While HTTP is a stateless, data only protocol, FTP is a... what's the opposite of "stateless"? Statefull? It keeps an opened connection until closed explicitly, and differenciates between one file and another, which is why you can easily manipulate multiple files over a single FTP connection.Honestly, I'm not sure why aren't we using FTP for everything, instead of HTTP.... I mean, in theory, you can program an FTP server to execute a program (ala PHP) when a certain FTP URI is requested and give its output as a file, and you can program an FTP client to display the raw contents of a file in some fashion, depending on the file's extension or something else (ala MIME type). The only reason I am not doing it is because I don't know of an FTP server that lets me script FTP URIs... browsers already try to display files from FTP, so they're sort of ready.

[skaterdav85]

maybe http is used because it is faster than ftp? why is the http protocol called stateless? so to clarify, is ftp just one type of protocol to connect to a server and http is another type of protocol to connect to a server, and depending on the protocol, that is the type of server you're accessing (so the ftp protocol is accessing an ftp server and an http protocol is accessing a web server)?

[boen_robot]

so to clarify, is ftp just one type of protocol to connect to a server and http is another type of protocol to connect to a server, and depending on the protocol, that is the type of server you're accessing (so the ftp protocol is accessing an ftp server and an http protocol is accessing a web server)?

Exactly.A stateless protocol is one which doesn't remember your state as the exchange goes on. With HTTP, you open the connection, send the whole request, get the whole response, terminate the connection. With FTP, you open a connection, get some bytes of the file, send an ackoledgement packget ("yes, the data so far appears to be correct, thank you"), get more bytes, etc. and then send a packet saying "I'm still connected" every few seconds, until you want new data or you explicitly say "I'm going off now".I'm guessing you sort of have a point about the speed of HTTP. HTTP is faster than FTP for a single small file delivery, due to the less "bureaucracy", but at what price? If we were using FTP, we wouldn't need to worry about sessions, now used in pretty much every app, and being the main vulnerability everywhere - they'd be embedded in the protocol itself, and be secured by the server and client themselves. And if we were using FTPS (or SFTP; note FTPS != SFTP), we would also have an equivalent of HTTPS.

[skaterdav85]

Exactly.

so web servers access ftp servers to serve those files. are these types of servers on the same server with just different pieces of software, or are they actually different towers of hardware, like 2 standalone servers, one for FTP and the other for the web server?

I'm guessing you sort of have a point about the speed of HTTP. HTTP is faster than FTP for a single small file delivery, due to the less "bureaucracy", but at what price? If we were using FTP, we wouldn't need to worry about sessions, now used in pretty much every app, and being the main vulnerability everywhere - they'd be embedded in the protocol itself, and be secured by the server and client themselves. And if we were using FTPS (or SFTP; note FTPS != SFTP), we would also have an equivalent of HTTPS.

I'm sure there are plenty of resources online that make more in depth distinctions and why http was chosen as the primary protocol for the web, i just cant find any haha.

[boen_robot]

so web servers access ftp servers to serve those files. are these types of servers on the same server with just different pieces of software, or are they actually different towers of hardware, like 2 standalone servers, one for FTP and the other for the web server?

Not exactly. Every kind of server is a kind (a piece) of software, which usually runs on the same file system (i.e. the same computer) where the files it gives are. A web server doesn't need to connect to an FTP server - it just gets the file from the file system. Same with an FTP server, or any other kind of a server.

I'm sure there are plenty of resources online that make more in depth distinctions and why http was chosen as the primary protocol for the web, i just cant find any haha.

FTP servers and clients were never scripted to display contents directly to the user. Only recently have browsers learned to try and render content from FTP sites when the extensioin is known. FTP servers and clients were (and still are) tailored to display the contents of files and folders, and move them from one system to another, hence the "File Transfer Protocol". That's why HTTP beat it to the punch... I'm just saying FTP had (and theoretically still has) the potential to be used in the role HTTP is taking currently.

[skaterdav85]

Not exactly. Every kind of server is a kind (a piece) of software, which usually runs on the same file system (i.e. the same computer) where the files it gives are. A web server doesn't need to connect to an FTP server - it just gets the file from the file system. Same with an FTP server, or any other kind of a server.

oh ok thanks that clears it up for me!

[Synook]

There were other alternate protocols to HTTP, like Gopher, but they all died out for one reason or another...FTP just doesn't have the features of HTTP when it comes to sending hypertext documents over networks - no headers, etc. - also, it's much more clumsy, and requires both TCP and UDP connections over several ports. I suppose a stateless protocol also suits the stop-start nature of hypertext browsing - quick bursts of traffic surrounded by large silences. With FTP you'd either have to keep the (TCP) connection alive for not much reason, or re-connect every time, which is slow, also partly due to the extra handshaking needed... FTP is more suited to transferring large chunks of data over short periods of time, why, for example, it uses a UDP connection for the actual data transfer, and has it's "active" mode.I'm sure if someone tried hard enough they could write the infrastructure to deliver hypertext over FTP, but I doubt it would be more efficient than HTTP. The purposes they are designed for are just too different.