Occasionally XKCD makes a valid point. One example is

http://xkcd.com/732/

The latest example is

http://xkcd.com/949/

One insightful poster commented

"I suspect Randall often uses the webcomic to make people talk about 
some issue he's having to find out a solution. Not that I'm against 
that, I really want to find a better way of transferring files."

After reading several dozen forum posts, it seems nobody has a really 
good solution for doing this.

Post a reply to this message

On 12/09/2011 09:41 AM, Invisible wrote:

> The latest example is
>
> http://xkcd.com/949/
>
> After reading several dozen forum posts, it seems nobody has a really
> good solution for doing this.

I guess the problem is security. If you have two machines with an 
Ethernet cable between them, it's really quite easy to transfer files 
from one to the other. The trouble is, if *you* can connect to my home 
PC to retrieve a file, then ANY RANDOM INTERNET USER can connect to my 
PC and obtain that same file. (And possibly others, if I configured it 
wrong.) Problems get far worse if I'm expecting you to *send* me a file...

Then of course there's the fact that both PCs have to be switched on at 
the same time. That's probably only an issue for large files. Logically, 
there is only one way around this: a 3rd party server. That immediately 
means that some 3rd party has to pay for your file transfer. That means 
that either you pay them, or they spam you with adverts.

Me? I have a web server. (It costs money.) So I can use that. Safe in 
the knowledge that I can post a URL here, and I won't have half the 
POV-Ray forum DDoSing my home PC off the Internet. But if you don't 
already have something like that set up... oh dears.

Oh, and if you're not trying to transfer a file between *your* PC and 
another, but trying to explain to your auntie how to transfer a file to 
your uncle... suddenly "oh dears" doesn't even cover it.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> After reading several dozen forum posts, it seems nobody has a really 
> good solution for doing this.

  You can thank Windows for this. Traditionally in the unix world
transferring files from one computer to another has been one of the
most basic features (and it's the reason why there are so many ways
of doing that, including rsync, rcp, scp, ftp, sftp, wget, and so on).
Of course this requires for one of the computers to act as a server.
This is made difficult in Windows. (Yes, I know it's not impossible.
I didn't say that.)

  The other traditional method to send files is through irc. This has
worked in the unix world for something like 20 years. Given that irc is
mostly dead nowadays (it's too "old-fashioned") most people don't even
know what it is. This works perfectly in Windows too, if only irc was
still popular there.

  One of the most common modern variants of this, one which also works
easily in Windows, is skype. Of course many people refuse to use skype
out of principle (the same kind of principle as avoiding facebook).

  If you are regularly transferring files to someone, just make him install
skype.

-- 
                                                          - Warp

Post a reply to this message

On 12/09/2011 08:14 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> After reading several dozen forum posts, it seems nobody has a really
>> good solution for doing this.
>
>    You can thank Windows for this. Traditionally in the unix world
> transferring files from one computer to another has been one of the
> most basic features (and it's the reason why there are so many ways
> of doing that, including rsync, rcp, scp, ftp, sftp, wget, and so on).
> Of course this requires for one of the computers to act as a server.
> This is made difficult in Windows. (Yes, I know it's not impossible.
> I didn't say that.)

I don't know about "impossible". It's actually pretty simple. By 
default, *every* Windows PC acts as a fileserver. If you have two PCs on 
the same network, open Windows Explorer, type the name (or more likely 
IP address) of the other machine. The syntax "\\machine\c$" works by 
default. Type in the administrator password for the remote machine. You 
now have access to the entire local filesystem.

This is the default configuration. You don't have to do *anything* to 
make it work. It's worked since Windows NT 4.0, if not before.

I'm not aware of any Unix system which *defaults* to letting remote 
users access the entire filesystem if they know the root password. 
Probably because it's a stunningly bad idea, unless the local network is 
trusted. But anyway...

This obviously completely fails over the Internet. Or at least, you 
better *hope* it fails. Otherwise your Windows box is liable to get 
rooted very shortly...

(You can, of course, set up proper shared folders to give specific 
people specific access levels to different parts of the filesystem. And 
unlike editing a million HTTP-access files or twiddling text 
configuration files for an FTP client, it's as trivial as right-clicking 
the folder you want to share and saying "share this". Of course, it's 
only really useful if network-wide user authentication is set up, which 
is a whole *other* topic... And, again, it's designed for the LAN, not 
the Internet.)

While we're on the subject, by default you can log in to any remote 
Windows PC that you happen to know the administrator password to. No 
special software required. Again, try getting X11 to let you do that. 
Good luck.

>    The other traditional method to send files is through irc. This has
> worked in the unix world for something like 20 years. Given that irc is
> mostly dead nowadays (it's too "old-fashioned") most people don't even
> know what it is. This works perfectly in Windows too, if only irc was
> still popular there.

It's news to me that IRC is "dead". Indeed, I still use it from time to 
time.

...

I'm talking on an NNTP server, aren't I? o_O

>    One of the most common modern variants of this, one which also works
> easily in Windows, is skype. Of course many people refuse to use skype
> out of principle (the same kind of principle as avoiding facebook).
>
>    If you are regularly transferring files to someone, just make him install
> skype.

Doesn't have to be Skype. Various IM clients have this function too. The 
problem, generally, is the inexplicably slow transfer speeds.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Am 12.09.2011 22:17, schrieb Orchid XP v8:

> I'm not aware of any Unix system which *defaults* to letting remote
> users access the entire filesystem if they know the root password.
> Probably because it's a stunningly bad idea, unless the local network is
> trusted. But anyway...

To the contrary: Unix doesn't only let users who know the root password 
access the /filesystem/, but do /anything/ they like on the machine.

I would yet have to hear of any admin who only has local console access 
to the servers he administers.

That's why you normally keep root passwords a secret ;-)

> While we're on the subject, by default you can log in to any remote
> Windows PC that you happen to know the administrator password to. No
> special software required. Again, try getting X11 to let you do that.
> Good luck.

Depends on the server's configuration regarding X11. But you do know 
that X11 is not the only way to log on to a Unix machine, don't you?

> Doesn't have to be Skype. Various IM clients have this function too. The
> problem, generally, is the inexplicably slow transfer speeds.

Not inexplicabe if you're on an ADSL line. Hint: The "A" is for 
"asymmetric" ;-)

Post a reply to this message

On 12/09/2011 09:39 PM, clipka wrote:
> Am 12.09.2011 22:17, schrieb Orchid XP v8:
>
>> I'm not aware of any Unix system which *defaults* to letting remote
>> users access the entire filesystem if they know the root password.
>> Probably because it's a stunningly bad idea, unless the local network is
>> trusted. But anyway...
>
> To the contrary: Unix doesn't only let users who know the root password
> access the /filesystem/, but do /anything/ they like on the machine.

Well, yeah, if I'm on a default Windows box and I've got network access 
to a second default Windows box, I can log in to it interactively, I can 
access the entire filesystem, the entire registry, read the event log, 
run device manager on it, and a whole heap of other stuff. Without 
having to configure *anything*.

> That's why you normally keep root passwords a secret ;-)

Windows installations at home generally don't do this. (I blame MS, not 
the user.)

>> While we're on the subject, by default you can log in to any remote
>> Windows PC that you happen to know the administrator password to. No
>> special software required. Again, try getting X11 to let you do that.
>> Good luck.
>
> Depends on the server's configuration regarding X11. But you do know
> that X11 is not the only way to log on to a Unix machine, don't you?

Sure. But no other protocols are configured by default either. And with 
good reason: not turning stuff on by default is more secure.

>> Doesn't have to be Skype. Various IM clients have this function too. The
>> problem, generally, is the inexplicably slow transfer speeds.
>
> Not inexplicabe if you're on an ADSL line. Hint: The "A" is for
> "asymmetric" ;-)

I know how fast my upload speed is. And it isn't this slow. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:

> I'm not aware of any Unix system which *defaults* to letting remote
> users access the entire filesystem if they know the root password.
> Probably because it's a stunningly bad idea, unless the local network is
> trusted. But anyway...

Every unix system can do this with something like sshfs installed - on 
the client side only - and sshd running on the server.

Jim

Post a reply to this message

Am 12.09.2011 22:55, schrieb Orchid XP v8:

>>> Doesn't have to be Skype. Various IM clients have this function too. The
>>> problem, generally, is the inexplicably slow transfer speeds.
>>
>> Not inexplicabe if you're on an ADSL line. Hint: The "A" is for
>> "asymmetric" ;-)
>
> I know how fast my upload speed is. And it isn't this slow. :-P

Don't forget that with Skype you typically have a voice stream to be 
transmitted at the same time.

Post a reply to this message

On 12/09/2011 10:36 PM, clipka wrote:
> Am 12.09.2011 22:55, schrieb Orchid XP v8:
>
>>>> Doesn't have to be Skype. Various IM clients have this function too.
>>>> The
>>>> problem, generally, is the inexplicably slow transfer speeds.
>>>
>>> Not inexplicabe if you're on an ADSL line. Hint: The "A" is for
>>> "asymmetric" ;-)
>>
>> I know how fast my upload speed is. And it isn't this slow. :-P
>
> Don't forget that with Skype you typically have a voice stream to be
> transmitted at the same time.

I've never used Skype. But I've used various IM clients. And my point 
is, they all tend to be inexplicably slow to transfer files.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 9/12/2011 12:14, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> After reading several dozen forum posts, it seems nobody has a really
>> good solution for doing this.
>
>    You can thank Windows for this.

Nah. You can thank NAT for this.

> Traditionally in the unix world
> transferring files from one computer to another has been one of the
> most basic features (and it's the reason why there are so many ways
> of doing that, including rsync, rcp, scp, ftp, sftp, wget, and so on).

Note how all of those require a running server on a public IP address.

> Of course this requires for one of the computers to act as a server.
> This is made difficult in Windows. (Yes, I know it's not impossible.
> I didn't say that.)

Transferring files in Windows is trivial. You RDP into the other machine, 
and use copy/paste just like in the file manager. Or you mount the share off 
the other machine. Or let RDP mount the share for you.

It just requires you not be behind a NAT.

>    The other traditional method to send files is through irc. This has
> worked in the unix world for something like 20 years. Given that irc is
> mostly dead nowadays (it's too "old-fashioned") most people don't even
> know what it is. This works perfectly in Windows too, if only irc was
> still popular there.

All the chat programs still have this, including messanger and all (afaik) 
the other chat clients like jabber and AIM and such.

>     One of the most common modern variants of this, one which also works
> easily in Windows, is skype. Of course many people refuse to use skype
> out of principle (the same kind of principle as avoiding facebook).

The principle being "I don't route my phone calls through random third-party 
computers, especially those who haven't given me permission to use their 
public computer as a NAT bridge."

For example, you can't use skype in google because google has enough 
bandwidth that half the world would be routing their skype calls over 
google's links if you did.

>    If you are regularly transferring files to someone, just make him install
> skype.

Or any IM client, really.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 9/12/2011 14:39, Orchid XP v8 wrote:
> I've never used Skype. But I've used various IM clients. And my point is,
> they all tend to be inexplicably slow to transfer files.

They're generally not transferring directly between machines, since your 
machine is normally behind a NAT. There's a server with a public IP address 
in between.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 9/12/2011 15:56, Darren New wrote:
> Transferring files in Windows is trivial. You RDP into the other machine,

Which works, btw, even through NAT, thanks to Torreno or whatever it's called.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 09/12/2011 06:20 PM, Jim Henderson wrote:
> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>
>> I'm not aware of any Unix system which *defaults* to letting remote
>> users access the entire filesystem if they know the root password.
>> Probably because it's a stunningly bad idea, unless the local network is
>> trusted. But anyway...
>
> Every unix system can do this with something like sshfs installed - on
> the client side only - and sshd running on the server.
>
> Jim
yep .. that's what I use to get/put files between my system and the pov 
server ... both are "nix" machines. The ssh is just used to establish a 
secure connection, but the underlaying protocol is ftp to transfer 
files. BTW: there are windows versions of the the same tool set ... 
stelnet, sftp (etc) that I used when I was exclusive on a doze box

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.09.2011 22:17, schrieb Orchid XP v8:

> > I'm not aware of any Unix system which *defaults* to letting remote
> > users access the entire filesystem if they know the root password.
> > Probably because it's a stunningly bad idea, unless the local network is
> > trusted. But anyway...

> To the contrary: Unix doesn't only let users who know the root password 
> access the /filesystem/, but do /anything/ they like on the machine.

  Except that most unix systems have been configured so that you *can't*
log in as root remotely. The system simply refuses to accept the login.

  Anyways, that's besides the point of transferring files. Being able to
log in as root (remotely or not) has nothing to do with the ability to
transfer files from one computer to another.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> While we're on the subject, by default you can log in to any remote 
> Windows PC that you happen to know the administrator password to. No 
> special software required. Again, try getting X11 to let you do that. 
> Good luck.

  Did you know that the X windowing system was actually designed from the
very beginning to run remotely? Running it locally was just a "free" feature
on top of that.

  In fact, it still acts pretty much like if it was a remote server. It's
just that rather than being physically remote, it just is being run on the
same computer as the user is logged in. (That's what the DISPLAY environment
variable is all about. You can log in to another computer, eg. using ssh,
and run an X program there, and it will show up on your screen, as long as
the DISPLAY environment variable is properly set. That's because X programs
don't really care where they are running and where they are displayed. It's
abstracted away.)

  It's Windows that was designed to be a purely local system, and to which
remote running was patched in later.

-- 
                                                          - Warp

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:

> > I'm not aware of any Unix system which *defaults* to letting remote
> > users access the entire filesystem if they know the root password.
> > Probably because it's a stunningly bad idea, unless the local network is
> > trusted. But anyway...

> Every unix system can do this with something like sshfs installed - on 
> the client side only - and sshd running on the server.

  Anyways, sharing an entire file system is often overkill, if your goal
is to simply transfer one file to another person.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Of course this requires for one of the computers to act as a server.
> > This is made difficult in Windows. (Yes, I know it's not impossible.
> > I didn't say that.)

> Transferring files in Windows is trivial. You RDP into the other machine, 
> and use copy/paste just like in the file manager. Or you mount the share off 
> the other machine. Or let RDP mount the share for you.

  I like how to you everything in Windows is "trivial". Like using soft or
hard links (which, btw, I have still no idea how to do, regardless of your
assurances that it's very easy).

  (If this so "trivial", why haven't I ever heard of this "RDP"? Yes, this
is the first time in my life I hear of it. And it's not like I haven't been
using Windows pretty regularly for the past 15 years or so. Contrast me
knowing about tools like rsync, rcp, scp and wget, which arguably are not
the most obvious things in unix either. What is the difference?)

-- 
                                                          - Warp

Post a reply to this message

On 12/09/2011 11:58 PM, Darren New wrote:
> On 9/12/2011 14:39, Orchid XP v8 wrote:
>> I've never used Skype. But I've used various IM clients. And my point is,
>> they all tend to be inexplicably slow to transfer files.
>
> They're generally not transferring directly between machines, since your
> machine is normally behind a NAT. There's a server with a public IP
> address in between.

Quite. And that presumably is where the transfer is getting throttled.

Post a reply to this message

On 13/09/2011 08:22 AM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> While we're on the subject, by default you can log in to any remote
>> Windows PC that you happen to know the administrator password to. No
>> special software required. Again, try getting X11 to let you do that.
>> Good luck.
>
>    Did you know that the X windowing system was actually designed from the
> very beginning to run remotely? Running it locally was just a "free" feature
> on top of that.

Yes indeedy. (I also know that they got the usual meanings of "server" 
and "client" backwards too.)

Now I haven't tried it, but I'm told is approximately /impossible/ to 
actually configure X so that you can access it remotely. Even though 
that's its entire design goal.

>    It's Windows that was designed to be a purely local system, and to which
> remote running was patched in later.

And yet, Windows is the one where I run a command, type in the name of 
any networked PC, and I have remote access. By default. No special 
configuration required.

(OTOH, doesn't X allow more than one user to log in at once? With 
Windows, that's a special extra feature that costs $$$.)

Post a reply to this message

On 12/09/2011 10:20 PM, Jim Henderson wrote:
> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>
>> I'm not aware of any Unix system which *defaults* to letting remote
>> users access the entire filesystem if they know the root password.
>> Probably because it's a stunningly bad idea, unless the local network is
>> trusted. But anyway...
>
> Every unix system can do this with something like sshfs installed - on
> the client side only - and sshd running on the server.

Yes, if you /install stuff/ you can do it.

My point is that Windows lets you do this by default. Nothing to 
install, nothing to configure. It's the *default* configuration state, 
unless you purposely changed it.

Post a reply to this message

On 13/09/2011 08:16 AM, Warp wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 12.09.2011 22:17, schrieb Orchid XP v8:
>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>
>> To the contrary: Unix doesn't only let users who know the root password
>> access the /filesystem/, but do /anything/ they like on the machine.
>
>    Except that most unix systems have been configured so that you *can't*
> log in as root remotely. The system simply refuses to accept the login.
>
>    Anyways, that's besides the point of transferring files. Being able to
> log in as root (remotely or not) has nothing to do with the ability to
> transfer files from one computer to another.

Sure. My point was, if you do a default install of Windows, you /can/ 
get and put files to it remotely. Under Unix, you'd have to install some 
stuff and configure it before that would work. (Argue amongst yourselves 
which one is better...)

Post a reply to this message

On 09/13/2011 04:16 AM, Warp wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 12.09.2011 22:17, schrieb Orchid XP v8:
>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>
>> To the contrary: Unix doesn't only let users who know the root password
>> access the /filesystem/, but do /anything/ they like on the machine.
>
>    Except that most unix systems have been configured so that you *can't*
> log in as root remotely. The system simply refuses to accept the login.

generally true enough, but there's always exceptions, any system(s) 
expected to be able to pass a security audit wouldn't allow this, 
because YES it's generally considered bad practice, however there were 
occasions that grabbing the system console remote was/is necessary ... 
ie: problem with root filesystem (need for fsck before the filesystem is 
mounted), but the audit trail required an incident report to explain why 
the access occurred ... most if not all sys admin tasks /should/ be done 
via sudo/su2 so as to NOT break the audit trail. Our security expert was 
a fanatic about this ... he even came up with a "bone-head" trophy that 
you were expected to display prominently, so other members of the admin 
team could publicly ridicule you for using "root" without a good reason 
... mandate from above was that protecting R&D systems and data was 
SERIOUS business.
>
>    Anyways, that's besides the point of transferring files. Being able to
> log in as root (remotely or not) has nothing to do with the ability to
> transfer files from one computer to another.

yep ... general access was setup so that a user either through uid/gid 
affiliation gets effectively painted into a corner

Post a reply to this message

On 09/13/2011 05:06 AM, Invisible wrote:
> On 13/09/2011 08:22 AM, Warp wrote:
>> Orchid XP v8<voi### [at] devnull> wrote:
>>> While we're on the subject, by default you can log in to any remote
>>> Windows PC that you happen to know the administrator password to. No
>>> special software required. Again, try getting X11 to let you do that.
>>> Good luck.
>>
>> Did you know that the X windowing system was actually designed from the
>> very beginning to run remotely? Running it locally was just a "free"
>> feature
>> on top of that.
>
> Yes indeedy. (I also know that they got the usual meanings of "server"
> and "client" backwards too.)
>
> Now I haven't tried it, but I'm told is approximately /impossible/ to
> actually configure X so that you can access it remotely. Even though
> that's its entire design goal.

easy on "nix" systems ... through a socket!

>
>> It's Windows that was designed to be a purely local system, and to which
>> remote running was patched in later.
>
> And yet, Windows is the one where I run a command, type in the name of
> any networked PC, and I have remote access. By default. No special
> configuration required.
>
> (OTOH, doesn't X allow more than one user to log in at once? With
> Windows, that's a special extra feature that costs $$$.)

Post a reply to this message

On 13/09/2011 08:30 AM, Warp wrote:

>    I like how to you everything in Windows is "trivial". Like using soft or
> hard links (which, btw, I have still no idea how to do, regardless of your
> assurances that it's very easy).

End users aren't supposed to use this technology. It's used "under the 
hood" by various Windows features. Remember, the desktop Windows OS is 
designed to be operated by morons.

(For example, most of our salesman have a Windows laptop. And trust me, 
they are idiots of the highest calibre.)

>    If this so "trivial", why haven't I ever heard of this "RDP"?

Because Microsoft refers to it by half a dozen different names.

Terminal Services.
Remote Desktop.
Remote Assistance.

RDP stands for Remote Desktop Protocol, and is the actual wire protocol 
underlying all of the above /product features/.

Terminal Services is where you have an expensive server-class version of 
Windows, you install all your complicated applications on that, and then 
end users use their Windows-based desktop PC to log into the server and 
run the applications on that. In other words, each desktop PC becomes 
essentially a dumb terminal for connecting to the server where the 
applications actually run.

Remote Desktop is where you log in to a remote desktop system in the 
same way you'd log in to it remotely. Except... it's remote. To anybody 
looking at the desktop locally, it just looks like the system is locked. 
Because it's a /desktop/ system, only one user can be logged in to it at 
once, remotely or locally.

Remote Assistance is where a computer wizard logs in to your PC 
remotely, but you still have control and you can see what they're doing. 
And there's a system for sending "help requests" or sending "help 
offers". And so forth.

I'm not 100% sure, but I think Windows Live Meeting might be using this 
as well. (It lets several people text or voice chat in realtime, and 
allows a "presenter" to share either a live video feed, or a live image 
of their desktop.)

What all these systems have in common is that one computer is displaying 
the video output of another. Like a remote X session. Except that it 
also connects the sound card, network drives, printers [but that never 
****ing works properly], clipboard, and probably a few other things as well.

This is literally how when I have a day off work, I can sit at my home 
PC and reboot servers, install software updates, and all kinds of other 
stuff, from my house. (Obviously, there's a VPN involved as well. 
Otherwise all this traffic would be unencrypted...)

Post a reply to this message

>> You can thank Windows for this.
>
> Nah. You can thank NAT for this.

I think it's more the general problem of Internet security. If you 
expose a service to the Internet, random people will try to hack it. 
Security is a Hard Problem.

> Note how all of those require a running server on a public IP address.

Well, yes. To perform a data transfer, you need a way to contact the 
other end.

I'm told there's a system called UPnP or something which is supposed to 
allow you to automatically bypass NAT. I have no idea whether this 
actually works. (It's the first time I've ever heard of it...) If it 
does work, NAT should be a non-issue.

>> Of course this requires for one of the computers to act as a server.
>> This is made difficult in Windows. (Yes, I know it's not impossible.
>> I didn't say that.)
>
> Transferring files in Windows is trivial. You RDP into the other
> machine, and use copy/paste just like in the file manager. Or you mount
> the share off the other machine. Or let RDP mount the share for you.

It's news to me that you can transfer files with RDP. Indeed, that's one 
of the frustrating things about it; it let's you control the remote 
machine, but not get data to it or from it.

>> If you are regularly transferring files to someone, just make him install
>> skype.
>
> Or any IM client, really.

Pretty much, yeah...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Under Unix, you'd have to install some 
> stuff and configure it before that would work. (Argue amongst yourselves 
> which one is better...)

  I really can't understand where you are getting this from. Not from what
I said, at least. I said that transferring files has been one of the core
features of unix from the very beginning. You make it sound like I had said
the exact opposite: That you need to do a lot of work to achieve that.

-- 
                                                          - Warp

Post a reply to this message

On 13/09/2011 11:12 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Under Unix, you'd have to install some
>> stuff and configure it before that would work. (Argue amongst yourselves
>> which one is better...)
>
>    I really can't understand where you are getting this from. Not from what
> I said, at least. I said that transferring files has been one of the core
> features of unix from the very beginning. You make it sound like I had said
> the exact opposite: That you need to do a lot of work to achieve that.

You said that it's always been easy to transfer files with Unix, and 
that Windows makes it far too difficult.

I said that Windows allows it *by default*, whereas under Unix you'd 
have to set up and configure a bunch of stuff first.

So, by my reckoning, transferring files is *easier* with Windows, not 
harder.

Now, if you want to talk about *security*, that's an entire other topic 
of course...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Now I haven't tried it, but I'm told is approximately /impossible/ to 
> actually configure X so that you can access it remotely. Even though 
> that's its entire design goal.

  I don't know what you mean.

  For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
(who is also running linux) and ran xclock. It opened nicely on my screen,
even though the program itself is running on my friend's computer (which is
physically located something like 200 km from here).

  (For some reason xclock is the de-facto "standard" X program to test
running X apps remotely. Probably because it's very light and ubiquitous
in all X installations.)

  Yes, you have to specify a special parameter to ssh in order to enable
X forwarding, but that's for safety reasons rather than anything else.

> >    It's Windows that was designed to be a purely local system, and to which
> > remote running was patched in later.

> And yet, Windows is the one where I run a command, type in the name of 
> any networked PC, and I have remote access. By default. No special 
> configuration required.

  What kind of configuration did I do to be able to log in into my friend's
computer and run an app remotely? Or to transfer files for that matter (which
was the original point)?

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 13/09/2011 08:30 AM, Warp wrote:

> >    I like how to you everything in Windows is "trivial". Like using soft or
> > hard links (which, btw, I have still no idea how to do, regardless of your
> > assurances that it's very easy).

> End users aren't supposed to use this technology. It's used "under the 
> hood" by various Windows features. Remember, the desktop Windows OS is 
> designed to be operated by morons.

  I don't think Windows uses soft links itself either. Soft links are
supported by NTFS, but I don't think Windows itself uses them for anything.
(After all, Windows has to be able to work if installed on a FAT32 partition
too.) Same's probably true for hard links.

  (And no, "shortcuts" are not soft links. They are a completely different
thing.)

-- 
                                                          - Warp

Post a reply to this message

On 13/09/2011 11:28 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> On 13/09/2011 08:30 AM, Warp wrote:
>
>>>     I like how to you everything in Windows is "trivial". Like using soft or
>>> hard links (which, btw, I have still no idea how to do, regardless of your
>>> assurances that it's very easy).
>
>> End users aren't supposed to use this technology. It's used "under the
>> hood" by various Windows features. Remember, the desktop Windows OS is
>> designed to be operated by morons.
>
>    I don't think Windows uses soft links itself either. Soft links are
> supported by NTFS, but I don't think Windows itself uses them for anything.
> (After all, Windows has to be able to work if installed on a FAT32 partition
> too.) Same's probably true for hard links.

I'm fairly sure System Restore uses hardlinks. (Not that you can tell by 
looking at it.) At least, it does on NTFS. On FAT, it presumably makes 
copies of the files. Then again, there's all sorts of features that 
don't work on FAT and only work on NTFS. (For example, I believe 
"offline folders" only works for NTFS.)

>    (And no, "shortcuts" are not soft links. They are a completely different
> thing.)

No, they aren't. They are special files that are interpreted by Windows 
Explorer. The hold no special significance for any other programs.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I said that Windows allows it *by default*

  So how exactly would I transfer a file to you from my Windows?

-- 
                                                          - Warp

Post a reply to this message

On 13/09/2011 11:25 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Now I haven't tried it, but I'm told is approximately /impossible/ to
>> actually configure X so that you can access it remotely. Even though
>> that's its entire design goal.
>
>    I don't know what you mean.
>
>    For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
> (who is also running linux) and ran xclock. It opened nicely on my screen,
> even though the program itself is running on my friend's computer (which is
> physically located something like 200 km from here).

Like I said, I haven't personally tried to run X remotely. (I wouldn't 
know how.) I'm told it requires spending hours editing the X 
configuration files to set up authentication and so forth, and then to 
make sure the server is started, and then to tell the application you 
want to run to open on the remote machine rather than the local one (by 
using CLI options that vary for every individual program so you have to 
look them up), and then...

And that's without encryption. If you want encryption, now you have to 
also install and configure an ssh server and client, set up 
authentication and encryption keys and god-knows what else.

>> And yet, Windows is the one where I run a command, type in the name of
>> any networked PC, and I have remote access. By default. No special
>> configuration required.
>
>    What kind of configuration did I do to be able to log in into my friend's
> computer and run an app remotely? Or to transfer files for that matter (which
> was the original point)?

So you're seriously telling me that with a default Linux install, not 
only is an ssh server installed, but it's actually configured to allow 
incoming connections and service them? And that X will actually work in 
this configuration?

I know nothing about X, but I do remember setting up my old laptop to be 
an ssh server so I could RDP into my Windows box over the Internet. It 
was a hellish nightmare of wading through manpages finding out how the 
hell to do what I actually wanted to do...

Post a reply to this message

On 13/09/2011 11:40 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I said that Windows allows it *by default*
>
>    So how exactly would I transfer a file to you from my Windows?

You can't. My PC is firewalled.

You also can't transfer a file using Unix, for the same reason.

That said, Windows file sharing is designed for the LAN. It really 
doesn't work properly over the Internet. You would need some kind of VPN 
connection to make it work properly. Unix, on the other hand, has tools 
which *do* work over the Internet. Things like FTP and so forth.

If both machines are on the same LAN, sharing files between Windows 
hosts becomes trivial.

Post a reply to this message

Le 2011-09-13 06:46, Invisible a écrit :
> On 13/09/2011 11:40 AM, Warp wrote:
>> Invisible<voi### [at] devnull> wrote:
>>> I said that Windows allows it *by default*
>>
>> So how exactly would I transfer a file to you from my Windows?
>
> You can't. My PC is firewalled.
>
> You also can't transfer a file using Unix, for the same reason.
>
> That said, Windows file sharing is designed for the LAN. It really
> doesn't work properly over the Internet. You would need some kind of VPN
> connection to make it work properly. Unix, on the other hand, has tools
> which *do* work over the Internet. Things like FTP and so forth.
>
> If both machines are on the same LAN, sharing files between Windows
> hosts becomes trivial.

If both Unix machines  are on a LAN, sharing files becomes as trivial.

There are Linux distros that start ftpd, remote shell and NFS by 
default, or at least ask you if you want to do it at installation time.

Same thing for Solaris, AIX and other *NIX variants.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-13 04:07, Invisible a écrit :
> On 12/09/2011 10:20 PM, Jim Henderson wrote:
>> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>>
>> Every unix system can do this with something like sshfs installed - on
>> the client side only - and sshd running on the server.
>
> Yes, if you /install stuff/ you can do it.
>
> My point is that Windows lets you do this by default.
 > Nothing to install,

Correction: Everything required is installed as part of the default 
installation.

> nothing to configure.

Correction:  Everything is preconfigured as part of the default 
installation.

> It's the *default* configuration state,
> unless you purposely changed it.

SO, if I was to provide you with a Linux distro that had ftpd and sshd 
installed by default, and allowed remote root logins, would you concede 
the point?

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-13 06:42, Invisible a écrit :
> On 13/09/2011 11:25 AM, Warp wrote:
>> Invisible<voi### [at] devnull> wrote:
>>> Now I haven't tried it, but I'm told is approximately /impossible/ to
>>> actually configure X so that you can access it remotely. Even though
>>> that's its entire design goal.
>>
>> I don't know what you mean.
>>
>> For the sake of it, I just now tried to do a "ssh -X" to a friend's
>> computer
>> (who is also running linux) and ran xclock. It opened nicely on my
>> screen,
>> even though the program itself is running on my friend's computer
>> (which is
>> physically located something like 200 km from here).
>
> Like I said, I haven't personally tried to run X remotely. (I wouldn't
> know how.)

Google X-Windows HOWTO.

It's almost like people have sorted this out 20 years ago.

> I'm told it requires spending hours editing the X
> configuration files to set up authentication and so forth,

So, basically, your only gripe with UNIx is that userIDs are important, 
whereas a standard Windows home edition assumes everything is honky dory 
with Administrator.

> and then to make sure the server is started,

And you don't need to do do that on Windows?  Try remote logging on a 
server that had Terminal Services disabled, or crashed, since it's one 
of the few services that can not be remote-restarted by pstools.

> and then to tell the application you
> want to run to open on the remote machine rather than the local one (by
> using CLI options that vary for every individual program so you have to
> look them up), and then...

Add

export DISPLAY=my.pcs.ip.address:screenno

To your login script and then EVERY X program will run on your screen, 
not the remote machine's.  Where did you get the idea that the CLI 
argument would differ from one program to the next, if you've obviously 
haven't RTMFed?

> And that's without encryption. If you want encryption, now you have to
> also install and configure an ssh server and client, set up
> authentication and encryption keys and god-knows what else.

Installing an ssh server on your *NIX machine is relatively easy. 
Probably easier than making the required regisrty hacks to install 
Terminal Services on a Windows XP home edition.

Installing an ssh client on the other end is trivial.

>
> So you're seriously telling me that with a default Linux install, not
> only is an ssh server installed, but it's actually configured to allow
> incoming connections and service them? And that X will actually work in
> this configuration?

Depending on the distribution, yes.  Distros aimed at desktop users 
(Ubuntu, Gentoo, etc...) will usually not have these on by default, but 
"server" distributions (SLES, Red Hat, Etc...) will have them on by 
default, or as I mentioned in another post, will ask you at installation 
time.

This is exactly the same for Windows.  Compare the options and default 
settings between a Home edition, Profesionnal edition or the Advanced 
server  versions.

>
> I know nothing about X, but I do remember setting up my old laptop to be
> an ssh server so I could RDP into my Windows box over the Internet. It
> was a hellish nightmare of wading through manpages finding out how the
> hell to do what I actually wanted to do...



-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>> It's the *default* configuration state,
>> unless you purposely changed it.
>
> SO, if I was to provide you with a Linux distro that had ftpd and sshd
> installed by default, and allowed remote root logins, would you concede
> the point?

It's news to me that any distro actually does this. But sure, then I 
could concede that Windows and Linux both make it equally trivial.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 13/09/2011 11:40 AM, Warp wrote:
> > Invisible<voi### [at] devnull>  wrote:
> >> I said that Windows allows it *by default*
> >
> >    So how exactly would I transfer a file to you from my Windows?

> You can't. My PC is firewalled.

> You also can't transfer a file using Unix, for the same reason.

  Most firewalls have the ssh port open because it's considered safe.
(And if it's not, it's easy to open in most distros).

  Then you can use scp, rsync or any equivalent tool to transfer files.
(There probably isn't any linux distro that doesn't come by default with
scp and rsync.)

  (Btw, the great thing about rsync is that it can resume interrupted file
transfers, a rather important feature that, oddly, most file transfer tools
completely lack.)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 13/09/2011 11:25 AM, Warp wrote:
> > Invisible<voi### [at] devnull>  wrote:
> >> Now I haven't tried it, but I'm told is approximately /impossible/ to
> >> actually configure X so that you can access it remotely. Even though
> >> that's its entire design goal.
> >
> >    I don't know what you mean.
> >
> >    For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
> > (who is also running linux) and ran xclock. It opened nicely on my screen,
> > even though the program itself is running on my friend's computer (which is
> > physically located something like 200 km from here).

> Like I said, I haven't personally tried to run X remotely. (I wouldn't 
> know how.) I'm told it requires spending hours editing the X 
> configuration files to set up authentication and so forth, and then to 
> make sure the server is started, and then to tell the application you 
> want to run to open on the remote machine rather than the local one (by 
> using CLI options that vary for every individual program so you have to 
> look them up), and then...

> And that's without encryption. If you want encryption, now you have to 
> also install and configure an ssh server and client, set up 
> authentication and encryption keys and god-knows what else.

  Didn't you read what I wrote above?

  Short answer: No, you don't. (I didn't have to do any configuration to get
that test working. I just did it, and it worked. The only thing I had to
know was that you have to give ssh the parameter -X to enable X forwarding,
which is disabled by default for safety reasons. And the connection is,
obviously fully encrypted because it happens through ssh.)

> So you're seriously telling me that with a default Linux install, not 
> only is an ssh server installed, but it's actually configured to allow 
> incoming connections and service them? And that X will actually work in 
> this configuration?

  I don't remember if sshd is enabled by default on OpenSuse, but it's
as easy to enable as doing a couple of mouse clicks (and typing the root
password, so that yast can perform the system modifications). IIRC it even
offers you to automatically open the ssh port on the firewall.

-- 
                                                          - Warp

Post a reply to this message

Le 2011-09-13 04:21, Invisible a écrit :
> On 13/09/2011 08:30 AM, Warp wrote:
>
>> I like how to you everything in Windows is "trivial". Like using soft or
>> hard links (which, btw, I have still no idea how to do, regardless of
>> your
>> assurances that it's very easy).
>
> End users aren't supposed to use this technology. It's used "under the
> hood" by various Windows features. Remember, the desktop Windows OS is
> designed to be operated by morons.
>
> (For example, most of our salesman have a Windows laptop. And trust me,
> they are idiots of the highest calibre.)
>
>> If this so "trivial", why haven't I ever heard of this "RDP"?
>
> Because Microsoft refers to it by half a dozen different names.
>
> Terminal Services.
> Remote Desktop.
> Remote Assistance.
>
> RDP stands for Remote Desktop Protocol, and is the actual wire protocol
> underlying all of the above /product features/.
>
> Terminal Services is where you have an expensive server-class version of
> Windows, you install all your complicated applications on that, and then
> end users use their Windows-based desktop PC to log into the server and
> run the applications on that. In other words, each desktop PC becomes
> essentially a dumb terminal for connecting to the server where the
> applications actually run.

Nope, that's Citrix (it may have changed names since MS acquired them, 
but everyone in the industry still calls it Citrix) and it runs on a 
different port than RDP.  Terminal Services is the service running on 
the remote machine that receives the connection from MSRTC.EXE running 
on your computer to allow remote desktop connections.

>
> Remote Desktop is where you log in to a remote desktop system in the
> same way you'd log in to it remotely. Except... it's remote. To anybody
> looking at the desktop locally, it just looks like the system is locked.
> Because it's a /desktop/ system, only one user can be logged in to it at
> once, remotely or locally.

Nein.  You can have two remote sessions on top of the "console" session 
on a machine running Terminal Services.  since NT4.

> What all these systems have in common is that one computer is displaying
> the video output of another. Like a remote X session. Except that it
> also connects the sound card, network drives, printers [but that never
> ****ing works properly], clipboard, and probably a few other things as
> well.

Sound card, printers, clipboard and drive mappings are all optional and 
off by default, on the client side.

>
> This is literally how when I have a day off work, I can sit at my home
> PC and reboot servers, install software updates, and all kinds of other
> stuff, from my house. (Obviously, there's a VPN involved as well.
> Otherwise all this traffic would be unencrypted...)

So why were you griping about having to install ssh because X11 was 
unencrypted?

The VPN tunnel also allows you to bypass the NAT done by your company's 
firewall.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>>     So how exactly would I transfer a file to you from my Windows?
>
>> You can't. My PC is firewalled.
>
>> You also can't transfer a file using Unix, for the same reason.
>
>    Most firewalls have the ssh port open because it's considered safe.
> (And if it's not, it's easy to open in most distros).
>
>    Then you can use scp, rsync or any equivalent tool to transfer files.
> (There probably isn't any linux distro that doesn't come by default with
> scp and rsync.)

No, I mean there's a *hardware* firewall in the way. You know, with the 
big Cisco sticker on it and the 3-digit price tag? (Although obviously 
that's only because I'm at work right now. My house doesn't have one of 
those...)

>    (Btw, the great thing about rsync is that it can resume interrupted file
> transfers, a rather important feature that, oddly, most file transfer tools
> completely lack.)

It's certainly an important feature. And yes, lots of tools seem to lack it.

I was under the impression that HTTP (and possibly FTP) support resuming 
partial downloads. (But not all servers bother to implement this.)

Actually, I was wondering... can you use rsync to synchronise, say, the 
files on an external storage device? Or does it only work if the other 
endpoint is a *computer*?

Post a reply to this message

>> Terminal Services is where you have an expensive server-class version of
>> Windows, you install all your complicated applications on that, and then
>> end users use their Windows-based desktop PC to log into the server and
>> run the applications on that. In other words, each desktop PC becomes
>> essentially a dumb terminal for connecting to the server where the
>> applications actually run.
>
> Nope, that's Citrix (it may have changed names since MS acquired them,
> but everyone in the industry still calls it Citrix) and it runs on a
> different port than RDP. Terminal Services is the service running on the
> remote machine that receives the connection from MSRTC.EXE running on
> your computer to allow remote desktop connections.

As far as I'm aware, Citrix is a completely different product made by a 
completely different company. Terminal Services is just another instance 
of the general RDP protocol.

>> Remote Desktop is where you log in to a remote desktop system in the
>> same way you'd log in to it remotely. Except... it's remote. To anybody
>> looking at the desktop locally, it just looks like the system is locked.
>> Because it's a /desktop/ system, only one user can be logged in to it at
>> once, remotely or locally.
>
> Nein. You can have two remote sessions on top of the "console" session
> on a machine running Terminal Services. since NT4.

Now reread what I wrote. For a *desktop* edition of Windows, you can 
only have one user logged in at once. (Because, let's face it, otherwise 
why would companies pay 400x more for the server version?)

>> What all these systems have in common is that one computer is displaying
>> the video output of another. Like a remote X session. Except that it
>> also connects the sound card, network drives, printers [but that never
>> ****ing works properly], clipboard, and probably a few other things as
>> well.
>
> Sound card, printers, clipboard and drive mappings are all optional and
> off by default, on the client side.

Really? It appears that they're all *on* by default in my testing...

Or maybe they changed it in some version of the RDP client? I know 
printing used to require that the same printer drives (*exactly* the 
same printer drivers) are installed on client and server, whereas now it 
works without that.

> So why were you griping about having to install ssh because X11 was
> unencrypted?
>
> The VPN tunnel also allows you to bypass the NAT done by your company's
> firewall.

Puzzling thing: There are many, many SSH clients for Windows. There are 
no SSH *servers*. And I have literally no idea why.

Post a reply to this message

>> So you're seriously telling me that with a default Linux install, not
>> only is an ssh server installed, but it's actually configured to allow
>> incoming connections and service them? And that X will actually work in
>> this configuration?
>
>    I don't remember if sshd is enabled by default on OpenSuse, but it's
> as easy to enable as doing a couple of mouse clicks (and typing the root
> password, so that yast can perform the system modifications). IIRC it even
> offers you to automatically open the ssh port on the firewall.

Damn. Setting up SSH has got a whole lot easier than when I tried to do 
it with Debian a few years ago.

I'm presuming it defaults to password authentication though? As I 
recall, half the trouble was figuring out how to permanently and 
irrevocably disable password authentication and *only* allow public key 
authentication. (For one thing, you have to work out how to create a 
keypair...)

Post a reply to this message

On 13/09/2011 03:21 PM, Invisible wrote:
>>> Terminal Services is where you have an expensive server-class version of
>>> Windows,
>>
>> Nope, that's Citrix (it may have changed names since MS acquired them,
>> but everyone in the industry still calls it Citrix) and it runs on a
>> different port than RDP. Terminal Services is the service running on the
>> remote machine that receives the connection from MSRTC.EXE running on
>> your computer to allow remote desktop connections.
>
> As far as I'm aware, Citrix is a completely different product made by a
> completely different company. Terminal Services is just another instance
> of the general RDP protocol.

http://en.wikipedia.org/wiki/Remote_Desktop_Services

Terminal Services most definitely *is* RDP. So is Remote Assistance. 
Exactly as I claimed.

http://en.wikipedia.org/wiki/Citrix

Citrix was not "acquired" by MS at all.

MS got the idea for Terminal Services from Citrix, but the actual wire 
protocol appears to be derived from PictureTel.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >>>     So how exactly would I transfer a file to you from my Windows?
> >
> >> You can't. My PC is firewalled.
> >
> >> You also can't transfer a file using Unix, for the same reason.
> >
> >    Most firewalls have the ssh port open because it's considered safe.
> > (And if it's not, it's easy to open in most distros).
> >
> >    Then you can use scp, rsync or any equivalent tool to transfer files.
> > (There probably isn't any linux distro that doesn't come by default with
> > scp and rsync.)

> No, I mean there's a *hardware* firewall in the way. You know, with the 
> big Cisco sticker on it and the 3-digit price tag? (Although obviously 
> that's only because I'm at work right now. My house doesn't have one of 
> those...)

  And that hardware firewall is completely incapable of forwarding ssh
connections? Pretty useless, I'd say.

> Actually, I was wondering... can you use rsync to synchronise, say, the 
> files on an external storage device? Or does it only work if the other 
> endpoint is a *computer*?

  Try http://en.wikipedia.org/wiki/Rsync

-- 
                                                          - Warp

Post a reply to this message

>> No, I mean there's a *hardware* firewall in the way. You know, with the
>> big Cisco sticker on it and the 3-digit price tag? (Although obviously
>> that's only because I'm at work right now. My house doesn't have one of
>> those...)
>
>    And that hardware firewall is completely incapable of forwarding ssh
> connections? Pretty useless, I'd say.

No, I don't have the password to configure it. (And besides, have *you* 
tried configuring Cisco stuff? It's not exactly intuitive. You probably 
need Certified Engineer status to figure it out.)

>> Actually, I was wondering... can you use rsync to synchronise, say, the
>> files on an external storage device? Or does it only work if the other
>> endpoint is a *computer*?
>
>    Try http://en.wikipedia.org/wiki/Rsync

Hmm, interesting. It looks like this might be a convenient way to update 
my MP3 player...

Post a reply to this message

On 09/13/2011 11:06 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> On 13/09/2011 11:25 AM, Warp wrote:
>>> Invisible<voi### [at] devnull>   wrote:
>>>> Now I haven't tried it, but I'm told is approximately /impossible/ to
>>>> actually configure X so that you can access it remotely. Even though
>>>> that's its entire design goal.
>>>
>>>     I don't know what you mean.
>>>
>>>     For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
>>> (who is also running linux) and ran xclock. It opened nicely on my screen,
>>> even though the program itself is running on my friend's computer (which is
>>> physically located something like 200 km from here).
>
>> Like I said, I haven't personally tried to run X remotely. (I wouldn't
>> know how.) I'm told it requires spending hours editing the X
>> configuration files to set up authentication and so forth, and then to
>> make sure the server is started, and then to tell the application you
>> want to run to open on the remote machine rather than the local one (by
>> using CLI options that vary for every individual program so you have to
>> look them up), and then...
>
>> And that's without encryption. If you want encryption, now you have to
>> also install and configure an ssh server and client, set up
>> authentication and encryption keys and god-knows what else.
>
>    Didn't you read what I wrote above?
>
>    Short answer: No, you don't. (I didn't have to do any configuration to get
> that test working. I just did it, and it worked. The only thing I had to
> know was that you have to give ssh the parameter -X to enable X forwarding,
> which is disabled by default for safety reasons. And the connection is,
> obviously fully encrypted because it happens through ssh.)
>
>> So you're seriously telling me that with a default Linux install, not
>> only is an ssh server installed, but it's actually configured to allow
>> incoming connections and service them? And that X will actually work in
>> this configuration?
>
>    I don't remember if sshd is enabled by default on OpenSuse, but it's
> as easy to enable as doing a couple of mouse clicks (and typing the root
> password, so that yast can perform the system modifications). IIRC it even
> offers you to automatically open the ssh port on the firewall.
>
confirm this last part as I'm on OpenSuse as well ... t'was a piece of 
cake from Yast, but if you know the process the command-line method is 
not /that/ cumbersome either

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Damn. Setting up SSH has got a whole lot easier than when I tried to do 
> it with Debian a few years ago.

> I'm presuming it defaults to password authentication though? As I 
> recall, half the trouble was figuring out how to permanently and 
> irrevocably disable password authentication and *only* allow public key 
> authentication. (For one thing, you have to work out how to create a 
> keypair...)

  Hmm, for some reason the sshd configuration module of yast is not
installed by default nowadays (it used to be with older versions of
opensuse). Well, it can be installed easily enough, though. (Although,
admittedly, you have to first figure out that you have to do this. I don't
understand why it isn't installed by default.)

  But yes, you can select RSA or public key authentication there.

http://doc.opensuse.org/products/opensuse/openSUSE/opensuse-security/cha.ssh.html#sec.ssh.yast

-- 
                                                          - Warp

Post a reply to this message

On Tue, 13 Sep 2011 03:57:59 -0300, Jim Holsenback wrote:

> On 09/12/2011 06:20 PM, Jim Henderson wrote:
>> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network
>>> is trusted. But anyway...
>>
>> Every unix system can do this with something like sshfs installed - on
>> the client side only - and sshd running on the server.
>>
>> Jim
> yep .. that's what I use to get/put files between my system and the pov
> server ... both are "nix" machines. The ssh is just used to establish a
> secure connection, but the underlaying protocol is ftp to transfer
> files. BTW: there are windows versions of the the same tool set ...
> stelnet, sftp (etc) that I used when I was exclusive on a doze box

No, sshfs is different than sftp - sshfs actually uses fuse to allow you 
to mount the remote filesystem locally using just the sshd daemon.

Quite handy if you don't want to have an ftp daemon running.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 03:24:25 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
> 
>> > I'm not aware of any Unix system which *defaults* to letting remote
>> > users access the entire filesystem if they know the root password.
>> > Probably because it's a stunningly bad idea, unless the local network
>> > is trusted. But anyway...
> 
>> Every unix system can do this with something like sshfs installed - on
>> the client side only - and sshd running on the server.
> 
>   Anyways, sharing an entire file system is often overkill, if your goal
> is to simply transfer one file to another person.

Sure, that's what scp is for.

Jim

Post a reply to this message