1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
SEX is a F*EX companion: Stream EXchange
You can imagine SEX as network wide UNIX pipes with a relay between. This
can be usefull for piping data from A to B where A and B cannot establish
a direct connection, but both can connect by HTTP to the SEX-server. SEX
is a synchronous service in conjuction to F*EX which is asynchronous.
For seamless integration into the UNIX tool chain, there are the
shell-tools sexsend and sexget.
Using web browsers for sexing will not work, because they cannot handle
streams in a pipe. So far, there are only the UNIX clients. Feel free to
implement other clients for other operating systems :-)
Authentication is the same as with F*EX.
Example:
root@lanldap:/var/log: tail -f syslog | sexsend framstag@rus.uni-stuttgart.de
framstag@blubb:/tmp: sexget | grep ldap
If you need encryption, then use the standard UNIX toolbox and add a
appropriate program to the pipe, for example: openssl bf
Tips for using SEX for file exchange:
I have a lot of (administrative) accounts on even more hosts, where I have
to exchange a lot or big files. These hosts often cannot make direct
tcp-connects to each other, because of IP-filters, firewalls or missing
server software. Only outgoing connections are possible.
Therefore NFS, ssh or even ftp are no option.
Since today my solution was F*EX:
1) on source host send the files within a container to the F*EX-server:
fexsend -a container.tar file1 file2 ... .
2) read or copy the FEXURL with mouse
3) on destination host get container.tar from F*EX-server and extract it:
fexget FEXURL
tar xvf container.tar
rm container.tar
Backdraws:
- a lot of manually work
- creation of container.tar needs (a lot of) time
- container.tar needs (too much) disk space on source and destination host
and on the F*EX-Server
Small solution:
Usage of xx (wrapper for fexsend) eliminates manually handling of
container.tar. But it will be still created, only automatically.
The ressource problems are still there.
The new sexy solution:
I use SEX (Stream EXchange) instead of FEX (File EXchange)!
There is no more a temporary container.tar, but the files are transfered
as a stream with the new client sexxx!
An example (*):
On the source host:
root@obertux:~/bin# sexxx .
streaming:
./
./autopatch
./subsys
./pwsync
./cspread
./fspread
./spread
./iptconf
./esxbackup
./esxlist
./getxx
./rscreen
On the destination host:
framstag@flupp:/tmp: sexxx
extracting from stream:
drwxr-xr-x root/root 0 2010-08-06 12:48 ./
-rwxr-xr-x framstag/users 170 2010-01-20 13:26 ./autopatch
-rwxr-xr-x root/root 336 2006-02-02 15:15 ./subsys
-rwxr-xr-x root/root 278 2010-01-18 23:38 ./pwsync
lrwxrwxrwx root/root 0 2009-11-03 15:49 ./cspread -> spread
lrwxrwxrwx root/root 0 2009-11-03 15:49 ./fspread -> spread
-rwxr-xr-x root/root 10354 2010-02-12 14:49 ./spread
-rwxr-xr-x root/root 1380 2010-01-14 08:54 ./iptconf
-rwxr-xr-x root/root 116 2010-05-04 18:36 ./esxbackup
-rwxr-xr-x root/root 344 2010-05-06 13:33 ./esxlist
-rwxr-xr-x root/root 93 2010-08-06 12:32 ./getxx
-rwxr-xr-x 1000/users 173 2009-11-26 13:40 ./rscreen
Now I can transfer any files from a new installed (VM) server to my
admin workstation behin a firewall. Or the other direction.
(*) The example above has only a few kB, but one can use sexxx for many GB
or even TB!
On my VMs I get a throughput of 90 MB/s.
|
