programm issues--moving files back and forth

[Tyler Littlefield]

Hello,
Thanks; I guess I wasn't aware of asking how editing files might lead to the 
debate of DMZ. :)
I'll try to work more that way; it might help quite a bit.
I think I'll tunnel samba.
Currently I would just edit the files in SecureCRT, but when I use pico 
(Jaws or CRT, not sure which) does not track the cursur, or even read at 
all.


Thanks,
Tyler Littlefield
email: tyler at tysdomain.com
web: tysdomain-com
Visit for quality software and web design.
skype: st8amnd2005

----- Original Message ----- 
From: "luke" <speakup at lists.tacticus.com>
To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca>
Sent: Wednesday, November 26, 2008 1:06 PM
Subject: Re: programm issues--moving files back and forth


> On Wed, 26 Nov 2008, Tyler Littlefield wrote:
>
>> > > It appears to me as though you are looking at your problems in terms 
>> > > of
>> > > solutions, rather than defining the problem and solving the route 
>> > > causes.
> [.]
>> Most of my problems branch from lack of knowing that this tool was 
>> available,
>> etc. I try to track down a problem and work from there, in solving the
>> problem. I'm not totally sure what the origenal comment was supposed to
>> convey.
>
> That rather than solving the current problem, go and find out _why_ the
> problem happened.  Was it because of a lack of security?  Secure your
> system, and the problem will solve itself, rather than patching over it.
> Was it because you're using the wrong mail software for your purposes?
> Rather than fighting with your current software to make it fit the
> circumstances, find the one which does the job better out of the box.
>
> It's the idea of building on shaky foundations.  It's fine if you know you
> are building on shaky foundations, because then you won't build anything
> that you expect to last.  However if you are covering cracks with planks
> during the construction phase, and then thinking they can support the
> house which they were never intended to do, problems will start to pop up
> when it's too late to easily and cheaply start over.
>
> That said, it's hard to know what you need when you're just starting out,
> and as you say, one can not always be aware of what tools are out there
> for a particular task.  However, if you are well able to determine what it
> is that you are trying to achieve, you should be able to do some
> searching, and find out what tools are available.
>
> If 1,440 files per day are appearing in a directory, and you don't
> want them, you can write a cron job to do an rm through that directory on
> an hourly basis, and the files will be gone--poof: problem solved.
> You have found a solution to the problem, but haven't bothered to figure
> out the cause, and solve that instead.
> Because checking the process table and a few other things, will probably
> tell you that there is a program running once per minute, which creates
> a newly-named PID file for itself, and then doesn't clean up when it
> unexpectedly crashes.  If you can find that program, and can find out what
> it's doing, and check the logs, you'll probably be able to solve the
> crash, the program will clean up after itself in future, and poof: problem
> solved.  Only now several problems have been solved, including some you
> probably didn't know about yet (massively expanding log files, for
> example), all because you backtracked the cause, and solved the problem,
> not the symptom.
> In fact, thinking of this, wasn't it you with a similar situation,
> involving cron job problems mailing you empty messages?  You wanted to
> stop the messages, or make them go away, and until someone suggested it,
> you did not think to figure out and fix the problem with the particular
> cron job which was prompting them.  I think that was you.
>
> I will add, that key to asking for help, is providing all relevant
> information during the first iteration of the question.  The information
> about your router would have eliminated or quashed the DMZ debate.
>
> What ever the question is, provide the circumstances.  If it's a
> networking question particular to your setup, describe your network, and
> the devices on it, unless you really are expert enough to describe only
> the parts which you are 100% sure are at fault.
> If it's a network security question, describe your topology, and what
> firewalls, NATs, routers, gateways, bridges, modems, and systems are in
> play, and describe what ports you need open and why, if your question
> relates to ports.
>
> If you're asking how to mount files on machine A, which are located on
> machine B; and further how to edit them in-place: describe the operating
> systems, and network relationship, between those two machines, and explain
> which machine is to be the host, and which is to be the client.
> Re that question, I now believe I understand that the files at issue
> are on a Linux host, and you have a Windows client which needs to edit
> them.  However I may have that inverted.
> The Linux box is outside your network, one presumes on a DHCPed public
> address, and the windows client is on an private Class C address behind a
> NAT provided by something or other.
>
> If all that is right, then SSHFS isn't going to work, unless someone has
> ported it to Windows.  NFS would, and Samba would.
> If you don't trust Samba over a public network (and nor should you), then
> route it over a tunnel of some kind, such as a VPN (I have suggested
> OpenVPN for this, and a search on "samba over openvpn" returns interesting
> results), although if you can do it without Samba, that is probably
> preferable.
>
> The point is, only you know your full configuration.  You must be able to
> figure out _why_ the way you want to do something is a good/the only idea,
> or if in fact there is a far simpler arrangement available.
> For example: can you edit your files on Linux?  If so, but need to use
> Windows to do it for some reason, how about a Windows SSH client
> connection into Linux, wherein you can run nano or the like?
>
> I do not pretend to be fully aware of all of the Windows <> Linux file
> accessing options, so whether SSHFS has some how been ported, or NFS works
> for you, or a Linux fileserver would be better for your situation, or
> tunneling Samba is better, I can not really say.
> It is so much easier just to answer the question which is asked, but you
> run the risk of following advice which may not apply to your situation,
> because you did not describe your situation well enough, or did not know
> enough to be in that situation yet, in which case you end up hurting
> yourself, and thinking that those who answered gave bad advice.
>
> Try to look at every cry for help, as someone who had never heard of your
> situation (or you, or your network) might look at it, and anticipate the
> questions he would ask.  "Does this line of my question lead to other
> questions?"
> In so doing, you may realize that you have a deeper issue which, if
> rectified, would eradicate your problem.
>
> I'm not trying to set you off on some new and unusual path (E.G. don't try
> this at home), but faced with the router you described, I might very well
> DMZ a Linux box, put a second NIC in it, and firewall my whole network
> through the Linux box, leaving the router as nothing but a modem, only
> serving as a bridge between my Linux gateway and the world.  That would
> eliminate your file and Samba problem completely, as Samba running on your
> internal network, could see the private interfaces of the Windows and
> Linux machines, and would be blissfully untouched by the wide world of
> crackers just on the other side of the Linux NAT machine.
>
> Regards,
>
> Luke
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup