Okay - - - Who Speaks "Senile" ? - - - (regarding OS X security)

Post by Mark Conrad
Is there anyone out there over 80 years old who can explain "real" OSX
security to me, in simple terms, without resorting to "Terminal Hell"
techno-speak?

A lot of the higher level security measures can only be accessed
through the Terminal, or in some cases, a GUI front end for the
Terminal which can be just as complicated a beast to the average user,
i.e. sunShield etc.

Post by Mark Conrad
By "real" security I mean the realistic view that OS X _can_ be
broken into - - - not the garbage that is constantly spouted in this NG
that OS X is somehow immune to breakin by a skilled cracker.

That 'garbage' has some merit. If your computer holds a database of a
couple of tens of thousands of valid credit card numbers then I'd be a
little paranoid too. High level hackers will be taking aim. If your
worried about your tax returns falling into the wrong hands, the basic
GUI Mac security measures will prove more than adequate for your needs.

Post by Mark Conrad
Here is the "Lack of Progress" that I have suffered so far, in my
futile thrashing around, trying to get a reasonable level of security
for myself. (I run TB2 so I _need_ added security)

I'm not overly familar with TB2 but I'll go out on a limb and say I
expect it has some decent built in security.

Post by Mark Conrad
A) "The Happy Hacker" by Carolyn P. Meinel 1999
(general Unix security horror tales)

Not familar with it.

Post by Mark Conrad
B) "Mac OS X Maximum Security" 2003 ISBN 0-672-32381-8
(747 pages on general Mac security issues)

This is a great book if your administering a network or a server. It's
a little over the top for a home user, though I imagine there are some
tidbits in it worth knowing.

<clip>

Post by Mark Conrad
2) Next, I goofed by purchasing LittleSnitch, only to find out that it
was beyond my capability to properly configure.

I'd be glad to help. What specifically are you having trouble with?

Post by Mark Conrad
Not only that, but
browsing Google using the search term "LittleSnitch" turned up some
rumbles on page-2 of the results page that LittleSnitch itself was
guilty of "calling home" !!!
That is like the fox guarding the henhouse, because LittleSnitch is
supposed to _prevent_ an errant program from "calling home".
I did not yet check further, but the author of that message offered to
respond to posters concerning the details.

I think checking further may be in order.

Post by Mark Conrad
3) Next, I downloaded free "Paranoid Android", only to find that it did
not include any install or configure instructions. It was advertised
as doing about the same job as LittleSnitch.

Not familar with it.

Post by Mark Conrad
4) Next, I bought a "NetBarrier" bundled app' for $100, which is
advertised as an easy to setup alternative to OSX's builtin firewall.
I will see just how easy it is to set up, once it arrives.

I had it in the OS 9 days. Default configuration will probably be
adequate for starters. As you learn more you can configure it more.

You seem to have this 'all or nothing' approach to things. No one ever
went from zero to genious in one step. Start with what you know. Apply
what you learn as you go along. If your network and data are are so
sensitive that it can't wait hire an expert.

Mark Conrad

2005-04-07 04:25:07 UTC

Post by Chris Moore
You seem to have this 'all or nothing' approach to things. No one ever
went from zero to genious in one step.

Well I am getting somewhat discouraged. (with myself)

Like someone here once said, I have been at this for some time now,
without hardly anything to show for it.
(ever since OS 10.0, whenever that was)

I can't claim newbie status anymore, however every time I hear Unix
experts out there discussing any subject, I feel lost because I can't
follow their discussions at all.
(the recent SSH thread, for example)

What happened to the concept that computers were supposed to make
things simple for us?

Excuse the bitchin'. I realize as much as anyone that to use the
present OSX to full advantage, that one has to bury one's self in Unix
for 20 years, learning slowly by osmosis, because there is _no_ easy
way to learn Unix, at least as far as learning how to use Terminal
commands is concerned.

I had it in the OS 9 days. Default configuration will probably be
adequate for starters. As you learn more you can configure it more.

Gadd, I hope that I will be able to configure it more.

I hope I can learn enough by fiddling with NetBarrier that I will be
able to create my own "rules" for that firewall.

The main reason I went with NetBarrier instead of OSX's built-in
firewall is because Intego inc. told me that they would help me over
the rough spots, as far as setting it up and configuring it.

From what I have read so far about creating firewall rules, one has to
go through a complex juggling act involving the "order" of the rules,
also rather the rules are "general" or "specific", and a whole mess of
other considerations about rules.

Very easy to mess up, IMO.

That 'garbage' has some merit.

Oh I agree with that, to the extent that crackers have not _yet_
considered it worth their while to bother OS X users, especially
considering how easy it is to "crack" a Window's OS.

Post by Chris Moore
...<severe snipping>...the basic GUI Mac security measures
will prove more than adequate for your needs.

I do not want to fall into that trap, because I believe that attitude
could cause me a very rude awakening.

I prefer to err heavily on the side of "too much protection".

Anyhow, my attitude is a heck of a good excuse for learning a lot more
about security. ;-)

Post by Mark Conrad
A) "The Happy Hacker" by Carolyn P. Meinel 1999
(general Unix security horror tales)

Not familar with it.

That book, even though old, (1999) really opened my eyes to the sort
of damage that crackers can do to a Unix user. Very scary.

Post by Mark Conrad
"Mac OS X Maximum Security" 2003 ISBN 0-672-32381-8
(747 pages on general Mac security issues)

This is a great book if your administering a network or a server. It's
a little over the top for a home user, though I imagine there are some
tidbits in it worth knowing.

Yes indeed, that book is generally great on important details.

TB2 by its very nature is both a "network" and a "server", (or "host"
if you prefer that term} - - - a TB2 computer can even be a "client" at
the same time that it is being a "server".

For example, a TB2 "server" computer named "Foobar" could be serving a
file requested by a client computer named "Jason", at the same time as
"Foobar" is acting as a client by requesting a file to be served by
"Jason".

In other words, the two computers "Foobar" and "Jason" are both acting
like servers and clients, simultaneously.

The two files pass each other in transit, both files going in opposite
directions. Convoluted, isn't it.

Post by Chris Moore
I'd be glad to help. What specifically are you having trouble with?

Okay, you asked for it. ;-)

Having simpleton senile logic, I do not understand simple terms like
"server", "host", "client", etc., which is probably apparent by my
previous remarks. These confusing terms are bandied around in
computer literature, and never fully explained.

For example, Apple's remote control application, which is named
"Apple-Remote-Desktop", can not do a bunch of stuff that TB2 can do.

I am told that OS X already has a "client" ARD included free as part of
OS-X.

Now the "administrative" (server?) part of ARD has to be purchased,
for $200.

This administrative part of ARD is installed on only _one_ computer,
I am told. That one computer can "control" many ordinary OSX
machines.

However ordinary OS X machines can _not_ control the "administrative"
computer, like they would be able to do if they were using TB2.

So my question is, which of the computers in an ARD network are the
servers, and which computers are the clients.

Are they all clients? Are they all servers? Are they all both clients
and servers? (likely that last is correct)

My present understanding of what a "server" is, is merely a computer
that "serves" or "makes-available" something requested by a "client".

I am probably getting "server", "client", and "controlling-computer"
all mixed up with each other.

In other words, "controlling-computer" probably has nothing at all to
do with whether a computer is a "server" or a "client".

All very confusing to me, hinders me when I run across these terms
while I am trying to learn OS X advanced security stuff.

Mark-

Zaphod B

2005-04-07 07:26:27 UTC

Post by Mark Conrad
What happened to the concept that computers were supposed to make
things simple for us?

They do - for many. Don't foorget that. It all has to do with the user's
demands and needs - real or perceived (?). To my colleague who writes
memos, uses e-mail and browses the net every now and then, it does make
things simple. No-one ever said, however, that computers would be
correspondingly easy to make or program, or to configure in fine detail.
On the contrary, apparent user friendliness has almost always meant more
work backstage for those responsible.

--
/Z

Mark Conrad

2005-04-07 19:04:23 UTC

Post by Zaphod B
No-one ever said, however, that computers would be
correspondingly easy to make or program,
or to configure in fine detail.

They certainly imply it, however, when they make statements like:
"It is adequately explained in the man pages"

Near as I can see, the man pages "adequately explain" very little,
serving to do nothing more than to refresh the memory of a Unix expert.

Considering the likely extreme benefits to a Mac user in being able to
_fully_ comprehend and use a small fraction of the Unix commands, say
for example 50 of the approx' 900 commands, I find it downright amazing
that in the 30 years that Unix has been around, there is no such thing
as a series of books describing in detail the commands and their many
optional arguments, switches, options.

Google is a little bit of help, for a command like grep.

Heck, there is not even a book around that adequately describes what
each command is "good for", much less how to use the command.

For simplicity, I am ignoring all the many commands that have to do
with programming. I would guess that perhaps 600 of the 900 commands
might deal strictly with programming, but that still leaves 300
commands that could really improve a Mac user's "computer experience",
if and only if there were an easier way for him to learn how to use
those commands.

Seems to me this is a golden opportunity for some enterprising Unix
expert to start up an online "Terminal School" using Timbuktu, to teach
hard cases like me.

If they could get across their knowledge, I would be the first one to
recommend their online school to others.

Better get cracking, experts, because if I learn, I might just decide
to blow your cover and start up a _free_ online school.

As it is right now, most Mac users are crippled by not knowing and
using Terminal commands.

Sad thing is, they don't realize that they are crippled.

Mark-

Zaphod B

2005-04-07 21:02:26 UTC

Post by Mark Conrad
"It is adequately explained in the man pages"

"adequately for whom" becomes a good follow-up. Or for what _kind_ of
user. The CLI of the Mac was never meant for "the ordinary user",
really.

Post by Mark Conrad
Near as I can see, the man pages "adequately explain" very little,
serving to do nothing more than to refresh the memory of a Unix expert.

Exactly.

Post by Mark Conrad
Considering the likely extreme benefits to a Mac user in being able to
_fully_ comprehend and use a small fraction of the Unix commands, say
for example 50 of the approx' 900 commands,

I know maybe a dozen, and am able to use half. I have used Macs for
sicteen-seventeen years. I don't see what "extreme benefit" I'd gain -
for my usage - knowing more CLI commands.

Post by Mark Conrad
I find it downright amazing
that in the 30 years that Unix has been around, there is no such thing
as a series of books describing in detail the commands and their many
optional arguments, switches, options.

From "Unix for Dummies" and onwards, including reference books thicker
than your wall? Must be dozens in my local academic bookstore.

--
/Z

Mark Conrad

2005-04-08 11:07:55 UTC

Post by Zaphod B
From "Unix for Dummies" and onwards, including reference books thicker
than your wall? Must be dozens in my local academic bookstore.

I have browsed all those books for long hours in my local B&N
bookstore, including the foot thick one's.

Could not find a darn thing in them pertinant to understanding and
using commands like dd.

I had to go back to this NG and pester the Unix experts here in order
to learn the specifics of dd and how to use dd in a practical situation
like backing up an OS X partition.

Post by Zaphod B
I don't see what "extreme benefit" I'd gain -
for my usage - knowing more CLI commands.

But don't you see, that is just the point. There is nowhere you and I
can go to find the benefits, if any, from learning these commands.

That is why I loudly piss and moan about the lack of examples as to how
to tap this potentially valuable resource.

A lot depends on how you work, as to what you might need.

If somehow a Unix genius could look over your shoulder while you work,
I have no doubt he could point out to you how you personally could
benefit from using specific Terminal commands.

Now learning how to use the commands to benefit yourself is a very
daunting process, taking lots of time and effort. (unfortunately)

There is nothing magic about Terminal, but the Unix programmers who
created the commands did so to solve particular problems.

If those problems happen to coincide with our particular problems, we
are missing the boat if we don't take advantage of their work.

Computers are hard enough to use, as regards to using them for real
life constructive purposes.

I liken my Mac to an expensive Stradivarius violin. The "ordinary
user" of such a high quality violin can only extract foul noises from
it when he first starts using it.

The expert concert pianist can reap fame and fortune from the same
violin when he learns how to use it.

I don't know how to use my Mac violin, dammit. (sob, sniffle)

Mark-

Joe Davison

2005-04-09 16:33:48 UTC

...

Post by Mark Conrad
Could not find a darn thing in them pertinant to understanding and
using commands like dd.
I had to go back to this NG and pester the Unix experts here in order
to learn the specifics of dd and how to use dd in a practical
situation like backing up an OS X partition.

Post by Zaphod B
I don't see what "extreme benefit" I'd gain -
for my usage - knowing more CLI commands.

The problem with that statement is that it presumes the existence of
such a Unix genius. I would argue that while there are many
UnixGuru(TM)s, there are essentially zero UnixGenius(TM)es of the
caliber you seem to expect. If you had 10 carefully chosen UnixGurus
looking over your shoulder then when you worked you might sometimes have
all 10 point out something (different for each one) you could do better,
and maybe often you'd find that one of them would be able to offer a
suggestion -- but they wouldn't always agree, and the "carefully chosen"
would be to ensure you got gurus whos knowledge covered the breadth of
what you wanted to do.

My job for the past 15-20 years was Unix software tools development and
support. I taught new people the basics and helped them get work
done as well as developing new tools and teaching people how to use
them. I was in a department with probably at least 25 other UnixGuru
types and another 50 up and coming UnixGurus. There are lots of things
I would seek out another UnixGuru for, and I don't think there were any
UnixGurus who didn't consult with others. There's just too much to
know, one has to specialize to become an expert.

Post by Mark Conrad
Now learning how to use the commands to benefit yourself is a very
daunting process, taking lots of time and effort. (unfortunately)
There is nothing magic about Terminal, but the Unix programmers who
created the commands did so to solve particular problems.
If those problems happen to coincide with our particular problems, we
are missing the boat if we don't take advantage of their work.

Absolutely right. And there are gazillions of particular problems for
which people developed solutions. There are even zillions of
generalizations that were made so a single tool could be developed to
deal with the group.

Post by Mark Conrad
Computers are hard enough to use, as regards to using them for real
life constructive purposes.
I liken my Mac to an expensive Stradivarius violin. The "ordinary
user" of such a high quality violin can only extract foul noises from
it when he first starts using it.
The expert concert pianist can reap fame and fortune from the same
violin when he learns how to use it.
I don't know how to use my Mac violin, dammit. (sob, sniffle)

Do you suppose a 50 year old concert violinist knows everything there is
to know about her Stradavarius? I don't. But I suspect she can do
great things with it even so.

joe

Bob Harris

2005-04-08 01:24:48 UTC

Post by Zaphod B
No-one ever said, however, that computers would be
correspondingly easy to make or program,
or to configure in fine detail.

"It is adequately explained in the man pages"

No, they imply it is easy to use the GUI (dumbed down) portion of the
computer. Opening and looking under the hood is not the same thing.
And programming the GUI features is hard work, which can be gotten wrong
much more easily then getting it right.

Post by Mark Conrad
Near as I can see, the man pages "adequately explain" very little,
serving to do nothing more than to refresh the memory of a Unix expert.

UNIX man pages require you to read between the lines. It is more
important to see what is not said, then what is said. The man page
writers are often the programmers and they make way too many assumptions.

Also the quality of the man pages differs depending on the vendor
supplying the UNIX. I found the Digital Equipment Corporation Tru64
UNIX man pages to be better then some, but the Linux man page, and the
FreeBSD (the basis for Mac OS X man pages) to be much more terse.

Man pages come in sections. Section 1 and 8 tend to be commands with
section 8 focusing more on administrative commands. Section 2 is
operating system calls into the kernel. Section 3 are library calls,
section 4, 5, 6, and 7 tend to be more internal stuff, some describing
the layout of files, or device driver interfaces, etc...

Most command line users can live very well just using section 1
commands, and maybe a section 8 command from time to time.

Of course there are books, but each and every implementation of UNIX has
slight variations on what commands are available, and exactly how they
work. The core commands are generally all there and work mostly the
same, but even then something as basic and essential as cp or mv or rm
have different option sets depending on the vendor providing the UNIX.

So yes there are books, but that does not mean one book will accurately
describe it all.

Having said that, I always recommend this book for people that want to
understand "The UNIX Way".

The UNIX Programming Environment
by Kernighan and Pike

The first several chapters deal with using UNIX commands and writing
scripts and explains how to get the most out of UNIX.

While "The UNIX Programming Environment" is 20 years old, Brian
Kernighan and Rob Pike were there at the beginning of UNIX. Brian
Kernighan has co-written many of the first books about UNIX, and in my
opinion and excellent writer. Kernighan is also the 'K' in awk.

If you really want to understand "The UNIX Way" then reading "The UNIX
Programming Environment" is a good place to start.

Post by Mark Conrad
Google is a little bit of help, for a command like grep.
Heck, there is not even a book around that adequately describes what
each command is "good for", much less how to use the command.

Many UNIX commands are intended to be combined into pipelines. And as
such, a lot of them or the way the work does not make sense until you
put them before or after or in the middle of a command sequence.

Again "The UNIX Programming Environment" does an excellent job of
teaching this.

Post by Mark Conrad
For simplicity, I am ignoring all the many commands that have to do
with programming. I would guess that perhaps 600 of the 900 commands
might deal strictly with programming, but that still leaves 300
commands that could really improve a Mac user's "computer experience",
if and only if there were an easier way for him to learn how to use
those commands.
Seems to me this is a golden opportunity for some enterprising Unix
expert to start up an online "Terminal School" using Timbuktu, to teach
hard cases like me.
If they could get across their knowledge, I would be the first one to
recommend their online school to others.
Better get cracking, experts, because if I learn, I might just decide
to blow your cover and start up a _free_ online school.

Can never have too many UNIX experts. I say go for it.

Post by Mark Conrad
As it is right now, most Mac users are crippled by not knowing and
using Terminal commands.
Sad thing is, they don't realize that they are crippled.

There I disagree with you strongly. My Mom (she hasn't hit 80 yet, but
is headed in that direction on roller skates), uses an iMac, and she is
very happy using Mail, Safari, google, eBay, Appleworks, iTunes,
calculator, and iChat (text, audio, and especially video with my brother
and I). She is very happy using that small segment of Mac applications.

And my Mom is much more computer savvy than my sister.

There are tons and tons of people that are happy with mail and a
browser. They do not need a Terminal.

For me, I am a UNIX programmer. I make my living writing kernel level
file systems in UNIX operating systems. So I love the terminal, as well
a iTerm, and X11, and xterm. I have fink installed
(http://fink.sourceforce.net), I write shell scripts (sometimes big
shell scripts), I use tools like ssh, VNC, the compiler, and debugger,
etc...

But, but, but, I do not use iMovie, rarely use iPhoto or image capture,
calculator, iCal, font book, stickies, Appleworks, or Textedit. I do
not think that means I'm crippled or missing out on something.

The Terminal (or iTerm) are great and the UNIX commands do have a lot of
power, but just because most Mac users do not know or care about them
does not make them crippled. Or to put it another way, I have 100
channels on my Cable TV. I find I watch maybe 6 most of the time, and a
few others sometime, but most of the other channels I skip right over
and totally ignore. Just because there are a 100 channels does not mean
I need to watch them to be whole.

Having said all that, I think it is great that you want to learn some of
the command line interface. A lot of times it helps if you have
something you want to do, or at least some simple tasks that you can
achieve using the command line interface. That makes you look at the
commands differently from just trying to read all the commands and image
what they might be good for.

Bob Harris

Post by Mark Conrad
Mark-

Mark Conrad

2005-04-08 11:08:02 UTC

Post by Mark Conrad
As it is right now, most Mac users are crippled by not knowing and
using Terminal commands.
Sad thing is, they don't realize that they are crippled.

There I disagree with you strongly...<Mom example snipped>...

Aha, by thrashing out strong points of difference, often comes
enlightenment ;-)

While it is no doubt true that many Mac users get by famously without
ever touching a command line, other Mac users can definately benefit
from what the command line offers.

For example, because of the ambiguos nature of the man page
"explanations", I find it absoltely essential to experiment with
Terminal commands.

Often this experimentation, in the necessary process of learning,
backfires on me, destroying various critical system files or even the
partition structures of my disk.

A few years ago I pestered Unix experts here to teach me how to use the
dd command to do good image backup and restore. Needless to say, it
took them quite a long time to pound enough knowledge into my thick
skull to allow me to use that dd command for image backup purposes.

Now I use that command almost daily, fully confident that I can recover
from disaters that an ordinary backup utility could not handle.

To give you an idea of how this lonely _one_ dd command benefits me
personally, you have to understand that I like things neat and exact.

Jaguar's Disk Utility did this for me, it could create a 20 GB OSX
partition - - - exactly 20 GBs (21,474,836,480 bytes)

I was happy, the birds were chirping, the flowers were blooming,
everything was neat and tidy.

Then Apple, for some reason or other, changed Disk Utility in Panther
so it would no longer create my nice neat 20 GB partition.

Well that irked me no end, so I created my own 20 GB partition without
using Panther's Disk Utility. Only drawback is, it takes hours to do,
but the time is justified because partitioning is done so seldom.
(perhaps once a year)

The exact 20 GB partition worked fine and dandy.

...but what if my experimentation, done in the process of "learning",
damaged the partition structure?

No problem, my dd backup not only restores OS X itself, it also
restores the exact-sized directory structure.

A conventional backup util' is not capable of doing this.

So the birds are still chirping, the flowers are still blooming, and
everything is right with the world, despite any damage I inadvertantly
do to my OS X or its special partition.

Now just imagine the great benefits that would befall me if I learned
grep and how to use "regular expressions".

Right now, I have hundreds of long notes that are totally disorganized,
I can't find anything.

If I knew how to use grep, that situation would change radically, I
would at least be able to find stuff. grep, properly used, is _much_
more useful than any GUI tool in OS X, like Sherlock, for example.

So in summary I still maintain that there are great benefits to be had
by at least some Mac users, if they would "un-cripple" themselves and
learn how to use some Terminal commands - - - those commands that they
personally would benefit from knowing.

Mark-

Bob Harris

2005-04-09 04:26:18 UTC

Post by Mark Conrad
As it is right now, most Mac users are crippled by not knowing and
using Terminal commands.
Sad thing is, they don't realize that they are crippled.

There I disagree with you strongly...<Mom example snipped>...

Aha, by thrashing out strong points of difference, often comes
enlightenment ;-)
While it is no doubt true that many Mac users get by famously without
ever touching a command line, other Mac users can definately benefit
from what the command line offers.
For example, because of the ambiguos nature of the man page
"explanations", I find it absoltely essential to experiment with
Terminal commands.
Often this experimentation, in the necessary process of learning,
backfires on me, destroying various critical system files or even the
partition structures of my disk.
A few years ago I pestered Unix experts here to teach me how to use the
dd command to do good image backup and restore. Needless to say, it
took them quite a long time to pound enough knowledge into my thick
skull to allow me to use that dd command for image backup purposes.
Now I use that command almost daily, fully confident that I can recover
from disaters that an ordinary backup utility could not handle.
To give you an idea of how this lonely _one_ dd command benefits me
personally, you have to understand that I like things neat and exact.
Jaguar's Disk Utility did this for me, it could create a 20 GB OSX
partition - - - exactly 20 GBs (21,474,836,480 bytes)
I was happy, the birds were chirping, the flowers were blooming,
everything was neat and tidy.
Then Apple, for some reason or other, changed Disk Utility in Panther
so it would no longer create my nice neat 20 GB partition.
Well that irked me no end, so I created my own 20 GB partition without
using Panther's Disk Utility. Only drawback is, it takes hours to do,
but the time is justified because partitioning is done so seldom.
(perhaps once a year)
The exact 20 GB partition worked fine and dandy.
...but what if my experimentation, done in the process of "learning",
damaged the partition structure?
No problem, my dd backup not only restores OS X itself, it also
restores the exact-sized directory structure.
A conventional backup util' is not capable of doing this.
So the birds are still chirping, the flowers are still blooming, and
everything is right with the world, despite any damage I inadvertantly
do to my OS X or its special partition.
Now just imagine the great benefits that would befall me if I learned
grep and how to use "regular expressions".
Right now, I have hundreds of long notes that are totally disorganized,
I can't find anything.
If I knew how to use grep, that situation would change radically, I
would at least be able to find stuff. grep, properly used, is _much_
more useful than any GUI tool in OS X, like Sherlock, for example.
So in summary I still maintain that there are great benefits to be had
by at least some Mac users, if they would "un-cripple" themselves and
learn how to use some Terminal commands - - - those commands that they
personally would benefit from knowing.
Mark-

I think I object to characterizing people, like my Mom, as Crippled.
That woman makes the Energizer Bunny look like a slacker!. I can fully
understand a desire to learn more, and I applaud that.

I will again urge you to get a copy of

The UNIX Programming Environment
by Brian W. Kernighan and Rob Pike

Grep is discussed. Regular Expressions are discussed. What more could
you want?

Find a copy in a book store. Get some coffee or your preferred
bookstore beverage and see if you like it. If not, then don't buy it.

Regular expressions can be easy and very complex. 97% of the daily
regular expressions are simple, 2.5% are mildly more complex, and maybe
0.5% are over the top complex (totally made up numbers :-)

grep string file
grep string *wildcard*files*
grep string file | grep and.this.string.on.the.same.line
grep string file | grep -v but.not.this.string.on.the.same.line
grep string | grep ... | grep ... | grep ... | ...

egrep "string|or.this.string|or.this.string" file
grep -e string -e or.this.string -e or.this.string file

grep -i ignore.capitals file

vi `grep -l string *files*` # edit the files that have this string

for file in *files*
do
if grep -q string $file
then
do something with $file
fi
done

ls *files* | while read file
do
if grep -q string $file
then
do something with $file
fi
done

while read file
do
if grep -q string $file
do something with $file
fi
done <<EOD
file1
file2
file3
file4
file5
EOD

grep -l string *files* | while read file
do
do something with $file
done

grep -l string *files* | xargs ls -l

find directory.path -type f | xargs grep -l string | xargs more

Everywhere I've said string, a regular expression can be used. There
are entire books written about regular expressions.

Mastering Regular Expressions, Second Edition by Jeffrey E. F. Friedl
Regular Expression Recipes: A Problem-Solution Approach by Nathan A. Good

But you really do not need to get a book to use regular expressions in
most day to day searches.

'^abc' find string starting in column 1 of the line
'xyz$' find string just before the end of the line
'abc.xyz' find abc any single character followed by xyz
'abc.*xyz' find abc any number of characters followed by xyz
'^abc.*xyz$' find abc in column 1 and xyz at the end of the line
'[abc]' find lines with a or b or c in the line
'[^abc]' find lines that do not contain a nor b nor c in the line
'[0-9]' find lines with any number in it
'[^a-zA-Z]' find lines that contain no letters
'^[a-zA-Z]' find lines that start with a letter
'^[^a-zA-Z]' find lines that do not start with a letter
'[^1-9]0' find lines with numbers that begin with 0
'[^1-9]0[0-9]\+' find lines with numbers starting with 0

Meta characters I've used are
^ anchor to beginning of line
$ anchor to end of line
. match any single character
* match zero or more of the previous character
[...] match any character in between the square brackets
[^...] do not match any character between the sq brackets
[x-y] match a character in the range
[^x-y] do not match a character in the range
\+ match 1 or more of the previous character

If you need to match one of the meta characters, then precede the meta
character with a backslash

\^
\$
\.
\*
\[

There are many more regular expression meta characters, but the above in
grep will really handle most of the search needs in day to day searching.

And to make life more exciting, different utilities use Regular
Expressions, _BUT_ they often add little twists to the Regular
Expression syntax, and tools like Perl take regular expressions to a
whole new level.

When reading regular expressions, always start on the left and work your
way to the right. Generally any Regular Expression can be read, you
just need to parse all the meta characters left to right. Do not try to
read it as a whole.

But once you learn the basics of Regular Expressions, you can generally
understand, with a reference cheat sheet, almost any utilities Regular
Expression syntax without too much difficulty.

Actually, the grep man page has a short section on Regular Expressions
that is not all that bad. It does not cover everything on Regular
Expressions, but it is short and keeps things simple. That and some
experimentation might be all you need to get your toe in the door. The
rest is down hill from there.

OK, it is after midnight, and time for me to go to bed. If I stay awake
too much longer, my Mom will be getting up to start her day, and she
will see me on-line via iChat and then I'll have to chat with Mom
explaining why I'm up at 2 or 3 AM. I told you she puts the Energizer
Bunny to shame :-)

Bob Harris

Joe Davison

2005-04-09 16:46:29 UTC

Post by Bob Harris

Post by Mark Conrad
Now just imagine the great benefits that would befall me if I
learned grep and how to use "regular expressions".
Right now, I have hundreds of long notes that are totally
disorganized, I can't find anything.
If I knew how to use grep, that situation would change radically, I
would at least be able to find stuff. grep, properly used, is
_much_ more useful than any GUI tool in OS X, like Sherlock, for
example.

That might be true, if those files are ascii files that are line
oriented.

...

Post by Bob Harris
But once you learn the basics of Regular Expressions, you can
generally understand, with a reference cheat sheet, almost any
utilities Regular Expression syntax without too much difficulty.
Actually, the grep man page has a short section on Regular
Expressions that is not all that bad. It does not cover everything
on Regular Expressions, but it is short and keeps things simple.
That and some experimentation might be all you need to get your toe
in the door. The rest is down hill from there.

One more point from the sidelines.

Almost the only way to learn is by trying and making mistakes, as you
already know. In the case of regular expressions, it's almost certain
that you will need to learn in stages.

I learned how to make great use of regular expressions from using ed(1)
and grep(1) thousands of years ago (1975ish). I would read the manpages
and figure out how to do something -- often only a little bit. I'd use
it for awhile and then, when wanting to do something I knew the tool
could do but I didn't know, I'd go back to the manpage. Before long I
thought I understood the system fairly well. Then I found that if I'd
go back about once/month or once/quarter and reread the manpages I'd
find out things it could do I'd never imagined.

Trying to read and understand some of the unix manpages is like trying
to drink from a firehose -- there's just too much coming at you. Take
what you can, try it, use it, and then come back for more.

joe

Mark Conrad

2005-04-09 17:11:53 UTC

Post by Bob Harris
I will again urge you to get a copy of
The UNIX Programming Environment
by Brian W. Kernighan and Rob Pike

I will browse it. If it is written in a fashion that I can even
half-ways understand, I will buy it.

Post by Bob Harris
I think I object to characterizing people, like my Mom, as Crippled.

Aw c'mon, it should have been obvious by the context of my remark that
I was referring to "crippled" as regards to limited ability in usage of
computers, which has nothing at all to do with ambition or lazyness.

I think your Mom is doing great to even be using computers at all.

As an older person myself, I can tell you it is damn hard to comprehend
and use these infernal complicated contraptions.

Among other things, my short term memory is complety shot, I can barely
see the screen, my hearing is shot so I can't enjoy music which is a
big part of Macs. My muscular coordination is going so I find myself
accidentally deleting files by hitting the wrong key, or just becoming
generally befuddled and not realizing what I am doing when I am working
fast.

Using personal computers is costly, usually running from $1 to $5 a
day, depending on the model and how much software one buys.
(figuring a 5-year life of Macs, which I generally exceed here)

Being it's expensive, one should endeavor to make their Mac as useful
as it can be, which includes being able to reap benefits from Terminal.

Your post was very helpful in its detail about regular expressions. I
am going to file it in a big folder I have, devoted to grep.

Hopefully I will soon get the time needed to tackle grep.

Changing Mental Gears - - -
In an ideal world where remote-control app's of any sort were used
a lot more than they are presently, we would then have the ability to
learn _and_ teach each other much more efficiently than we do right
now.

Using RC app's would free us to "virtually" stand right by the shoulder
of a remote Mac user, point out stuff on his screen, talk back and
forth with him, shove him aside, sit at his keyboard, and
_demonstrate_ to him what keys to press, what icons to shove around,
and in general to do stuff with him that is almost impossible to do via
these NG postings.

The primitive way we Mac users operate in these NGs can be likened to
the Old-West days when it took a letter months to reach its
destination.

We post, wait a day or so for responses to some trivial point, worry
about bandwidth contamination from people who don't think exactly as we
think, wade through all the flames and misunderstandings.

With RC use, we would have instant response to our problems, instead of
doing stuff the Old-West way that we presently do.

I therefore think it is worthwhile to encourage more use of RC software.

I don't much care what brand of RC software either. TB2 has its
drawbacks, just like other RC app's have their drawbacks.

There is not much stopping us from having several different kinds of RC
app's in our Macs, to accomodate users who use different "main" RC
app's than we do.

The only reason I don't download the free VNC app' is because I
_perceive_ that it is hard to install and configure.

Mark-

Bob Harris

2005-04-09 20:22:26 UTC

Post by Bob Harris
I will again urge you to get a copy of
The UNIX Programming Environment
by Brian W. Kernighan and Rob Pike

I will browse it. If it is written in a fashion that I can even
half-ways understand, I will buy it.

I think it is interesting that this is a 20 year old book that I still
find in the computer UNIX section of some book stores (Barnes & Noble,
Borders, ...). It says a lot about the staying power of the book in a
book publishing field that cranks out thick books by the pound, that
come and go so quickly.

Post by Mark Conrad
I think I object to characterizing people, like my Mom, as Crippled.
Aw c'mon, it should have been obvious by the context of my remark that
I was referring to "crippled" as regards to limited ability in usage of
computers, which has nothing at all to do with ambition or lazyness.
I think your Mom is doing great to even be using computers at all.

I'm impressed by my Mom as well.

Post by Mark Conrad
As an older person myself, I can tell you it is damn hard to comprehend
and use these infernal complicated contraptions.
Among other things, my short term memory is complety shot, I can barely
see the screen, my hearing is shot so I can't enjoy music which is a
big part of Macs. My muscular coordination is going so I find myself
accidentally deleting files by hitting the wrong key, or just becoming
generally befuddled and not realizing what I am doing when I am working
fast.

Learning UNIX is good exercise for your brain. Keep it up.

Post by Mark Conrad
Using personal computers is costly, usually running from $1 to $5 a
day, depending on the model and how much software one buys.
(figuring a 5-year life of Macs, which I generally exceed here)
Being it's expensive, one should endeavor to make their Mac as useful
as it can be, which includes being able to reap benefits from Terminal.

It just means that the Mac is not just a pretty face, it has depth of
personality, and you are smart enough to look beyond the surface.

Post by Mark Conrad
Your post was very helpful in its detail about regular expressions. I
am going to file it in a big folder I have, devoted to grep.

Wait wait. You said somewhere you have lots of notes that are not well
organized, and you want to use grep to help find things. If you store
my notes about grep with the other notes, how will you ever find the
grep notes to help you use grep, so that you can find the grep notes, so
that you can use grep, so that ...

Post by Mark Conrad
Hopefully I will soon get the time needed to tackle grep.
Changing Mental Gears - - -
In an ideal world where remote-control app's of any sort were used
a lot more than they are presently, we would then have the ability to
learn _and_ teach each other much more efficiently than we do right
now.
Using RC app's would free us to "virtually" stand right by the shoulder
of a remote Mac user, point out stuff on his screen, talk back and
forth with him, shove him aside, sit at his keyboard, and
_demonstrate_ to him what keys to press, what icons to shove around,
and in general to do stuff with him that is almost impossible to do via
these NG postings.

It is the "shove him aside" part that most people worry about. No
problem with it is someone you trust, like a relative or close friend.
But accepting "Candy" from strangers on the internet is always worrying.

But with broadband becoming more and more common, video, audio, and
screen mirroring capabilities should be come more common.

One way to do this in safe mode, would be to use iChat AV, point your
iSight (or similar) camera at your screen and allow your guest to watch
what is on your screen, and talk your through it. That would be safe.

Post by Mark Conrad
The primitive way we Mac users operate in these NGs can be likened to
the Old-West days when it took a letter months to reach its
destination.
We post, wait a day or so for responses to some trivial point, worry
about bandwidth contamination from people who don't think exactly as we
think, wade through all the flames and misunderstandings.

Actually there are advantages to this form of communications. First it
is all text and that focuses people on communication skills, and not
just pretty pictures.

Text allows for easier archival <http://groups.google.com> storage of
postings that can be searched for previous answers.

Composing a reply allows the author more time to thing about what they
are saying. Although, I'll admin I don't think that much about it :-)

This forum allows multiple people to join in, and get a diverse set of
opinions/answers.

Post by Mark Conrad
With RC use, we would have instant response to our problems, instead of
doing stuff the Old-West way that we presently do.
I therefore think it is worthwhile to encourage more use of RC software.
I don't much care what brand of RC software either. TB2 has its
drawbacks, just like other RC app's have their drawbacks.
There is not much stopping us from having several different kinds of RC
app's in our Macs, to accomodate users who use different "main" RC
app's than we do.

I do use VNC to manage my Mom's iMac from 300 miles away. And I do use
a secure setup via an ssh tunnel. But then again, my Mom does trust me
to be able to take over control of her keyboard. And I did all the
setup work on visits to Mom, and I worked out all the steps I needed to
do in order to make it secure. She just gets the benefits.

It is an iMac after all, so I do not need to connect to her system too
often, but I might do software updates remotely, or she might call (or
iChat me) telling me she is having some problem or asking me how to do
something, and I'll connect while she is using an iChat audio (video
takes too much bandwidth that I need for transmitting the image of her
desktop), and I will either watch or do while she explains what she
wants.

Works great, but I would not want just anyone being able to take over
control of her system.

Post by Mark Conrad
The only reason I don't download the free VNC app' is because I
_perceive_ that it is hard to install and configure.

Not that hard. More interesting if you are trying to setup a very secure
environment.

Actually the setting up of OSXvnc or Share my Desktop is not hard, it is
making the secure connection via ssh and tunneling Chicken of the VNC
through the ssh tunnel.

And for the most part each step is not that hard, but combining the
steps for the VNC server, the ssh tunnel, the VNC client, and maybe even
dealing with finding the ever changing DHCP IP addresses assigned to the
target system running the VNC server because of the way most ISPs assign
IP addresses, makes it more difficult. If only this stuff worked as
easily as iChat AV sets up a video session, then it would be very nice.

But if for some reason you want to exercise your brain learning about
VNC, then I would suggest OSXvnc for the server and Chicken of the VNC
for the client.
http://www.versiontracker.com/dyn/moreinfo/macosx/16699
http://www.versiontracker.com/dyn/moreinfo/macosx/14099

The server does have a disable mouse and keyboard option so you can
allow someone to just watch if you want.

Post by Mark Conrad
Mark-

Bob Harris

Joe Davison

2005-04-09 16:15:54 UTC

Post by Zaphod B
No-one ever said, however, that computers would be
correspondingly easy to make or program,
or to configure in fine detail.

"It is adequately explained in the man pages"
Near as I can see, the man pages "adequately explain" very little,
serving to do nothing more than to refresh the memory of a Unix expert.
Considering the likely extreme benefits to a Mac user in being able
to _fully_ comprehend and use a small fraction of the Unix commands,
say for example 50 of the approx' 900 commands, I find it downright
amazing that in the 30 years that Unix has been around, there is no
such thing as a series of books describing in detail the commands and
their many optional arguments, switches, options.
Google is a little bit of help, for a command like grep.
Heck, there is not even a book around that adequately describes what
each command is "good for", much less how to use the command.
For simplicity, I am ignoring all the many commands that have to do
with programming. I would guess that perhaps 600 of the 900 commands
might deal strictly with programming, but that still leaves 300
commands that could really improve a Mac user's "computer
experience", if and only if there were an easier way for him to learn
how to use those commands.
Seems to me this is a golden opportunity for some enterprising Unix
expert to start up an online "Terminal School" using Timbuktu, to
teach hard cases like me.
If they could get across their knowledge, I would be the first one to
recommend their online school to others.
Better get cracking, experts, because if I learn, I might just decide
to blow your cover and start up a _free_ online school.
As it is right now, most Mac users are crippled by not knowing and
using Terminal commands.
Sad thing is, they don't realize that they are crippled.

"Crippled" seems an over statement. "Limited" might be more accurate.

I will fault unix systems more for making it difficult to find a command
I know must exist (or have even used before) but don't know the name
of. In olden times, when we all had paper unix manuals, there was a
command to produce a permuted index that arranged the synopses so one
could look things up by guessing a word... I suppose "apropos" has
replaced it, but it's not quite as good, because with the permuted
index, if you couldn't think of the right term, you could just scan the
listing until you spotted it.

Post by Mark Conrad
I realize as much as anyone that to use the
present OSX to full advantage, that one has to bury one's self in Unix
for 20 years, learning slowly by osmosis, because there is _no_ easy
way to learn Unix, at least as far as learning how to use Terminal
commands is concerned.

I've been using and programming on unix for over 30 years and there are
still many areas and commands I've never used. I'm sure there are even
things I'd like to do that could be easily done if only I knew about the
XXX command.

On the other hand, that doesn't bother me nearly as much as it seems to
bother you. It's a complex evolving system. 20 years ago I might have
thrown away the rest of my life and become a complete unix droid knowing
everything that could be know about it -- maybe. Even if I had, I'd
probably be in the same state I am now, assuming I'd then decided to go
back to having a life. Because there are many things commonly done on
unix systems in those days that don't get much use these days, like
dealing with tape drives (particularly DECtapes). On the other hand,
there are many things one could do with the system today that didn't
exist then. In truth, you'd have to bury yourself in Unix for your
entire life to stay on top of it.

But, a unix system isn't a chisle. A chisle you can spend a few years
with and learn all there is to know about it -- you'll probably continue
to get better at using it, but you'll probably know all there is to
know...

Maybe even a bicycle. Doubt you can do it with an automobile, though.
Do you still do all your own car maintenance?

Fact is, I learn to use such systems well enough. It's a trade off --
how much time to I want to spend learning and how much time do I want to
spend using -- and how much time do I want to spend living the rest of
my life.

I don't think one could even do what you want with a 64K CP/M
system -- there's just too much to know.

If someone is willing to pay me $100K/year to develop the sort of
learning resource you're looking for, I'd probably be willing to
undertake the effort. I'll even do individualized tutoring at a
comparable rate. In fact, I've spent time in this newsgroup doing it
for free, as you may recall.

But you need to recognize that part of what you're asking for requires
me not only to learn what the "best" commands do, but also to learn how
to explain them to the student. I think that's become easier with you
as student in the past couple of years, because you have spent some time
learning the basics, but it's still not trivial. One thing that can
make that part (adjusting to the student) is that many students
(including you in the early days) simply don't want to learn the
background needed to understand the answer -- they just want the answer
stated so they can understand it. "I don't want to understand
logarithms, I just want to be able to pass the test!" was a typical
statement when I was trying to tutor college algebra students.

Learning to use grep/egrep/fgrep is like almost anything else worth
learning -- you have to try and fail and try again. Unfortunately,
that group of tools is no longer as useful as it once was, because we're
moving away from line oriented ascii files with '\n' line terminators.
It's still great for programmers, but if you do most of your writing
with a modern word processor, it's just nowhere near as useful as it
was.

joe

Mark Conrad

2005-04-10 11:02:22 UTC

Post by Joe Davison
I've been using and programming on unix for over
30 years and there are still many areas
and commands I've never used.

Yes, but I would be willing to bet that you have the "meat" of Terminal
commands under your belt, and have no problem with using grep for
example.

You would have no trouble using dd and associated commands to create an
OSX image backup/restore program better than the one I have.

Where I use probably ten or twenty Terminal commands I use on a fairly
regular basis, you would likely have more like 100-200 of them that you
could use after a few minutes of reviewing the man pages.

Post by Joe Davison
It's a complex evolving system.

I don't believe it is evolving all that fast, it seems to be more
stagnant than you suggest. It relies on volunteers for any change at
all.

About a year or so ago, there was a big flap that they were finally
going to update the Lisp underpinnings of Emacs, i.e. to create a
modern version of Emacs that used Lexical scoping in its Lisp, instead
of the old fashioned dynamic scoping.

The aim was to make the Lisp language within Emacs more modern and
usable, like all modern Lisp languages are.

That effort stalled out, so the Lisp within Emacs is just as
old-fashioned and outdated as ever.

Post by Joe Davison
Learning to use grep/egrep/fgrep is like almost anything else worth
learning -- you have to try and fail and try again. Unfortunately,
that group of tools is no longer as useful as it once was, because we're
moving away from line oriented ascii files with '\n' line terminators.
It's still great for programmers, but if you do most of your writing
with a modern word processor, it's just nowhere near as useful as it
was.

I am confused. Are you saying that the regular search tools in a
modern word processor can do as good a job of searching as grep can?

Post by Joe Davison
...<heavily snipped>...simply don't want to learn the background
needed to understand the answer -- they just want the answer
stated so they can understand it.

Of course, I just want to learn how to use the car, I don't want to
clutter up my brain with the background of automotive theory.

Keep it simple, nothing wrong with that.

What is "needed to understand" in my estimation is very little.

We both disagree radically on this point.

Examples of usage are much more valuable than pages and pages of arcane
background.

Examples are noticably absent from the man pages, which makes the man
pages almost impossible to understand.

I will concede that _in_ _some_ _cases_ is is absolutely
essential that background basics be understood.

But a lot of the time background basics can be bypassed with no harm
done. An example in the "Scheme" dialect of Lisp follows below.

A good example of the value of "examples" is a small 185 page classic
Lisp training book named "The Little Lisper". It is almost completely
example based. Very complex and hairy concepts are easily learned by
using that small book.

This book was first written at MIT in 1987, and involves concepts so
hairy that they would curl the nose-hairs of the usual C programmer.

It starts with extremely simple examples, like:

Is it true that this is a list? () Yes

Then towards the end, the book shows examples of the derivation of a
recursive function called "the applicative-order Y combinator".

(define Y
(lambda (M)
((lambda (future)
(M (lambda (arg)
((future future) arg))) )
(lambda (future)
(M (lambda (arg)
((future future) arg))) ))) )

Almost impossible to explain to a Lisp student if you spring it on him
without using examples. (like the man pages of Unix do)

Note especially the section of code (future future) where the
function "future" takes as its argument the function "future".

In other words, "future" takes itself as an argument.

Never the less, the working of this complex "Y" function is explained
in the book by using examples, and believe it or not the student gains
a clear understanding of how the function works.

The book examples get even nastier, eliminating both the global
variable "Y" and eliminating "define", replacing define with its Lisp
primatives.

In other words, showing by example how "define" is made, in Lisp.

Post by Joe Davison
I'll even do individualized tutoring at a comparable rate.
In fact, I've spent time in this newsgroup
doing it for free, as you may recall.

...and I complement you for that. Likely, when you yourself started
with Unix, others probably helped you for free.

...although I hear from many that help was not all that easily come by,
compared to the help that is available today. (Google, etc.)

Mark-

Joe Davison

2005-04-10 21:17:47 UTC

Post by Joe Davison
I've been using and programming on unix for over
30 years and there are still many areas
and commands I've never used.

Yes, but I would be willing to bet that you have the "meat" of
Terminal commands under your belt, and have no problem with using
grep for example.
You would have no trouble using dd and associated commands to create
an OSX image backup/restore program better than the one I have.
Where I use probably ten or twenty Terminal commands I use on a
fairly regular basis, you would likely have more like 100-200 of them
that you could use after a few minutes of reviewing the man pages.

You're right, I probably have 100-200 commands I can use regularly, and
grep is certainly one of them. However, I've not needed to use dd since
I learned to use ar(1) in about 1975. I'm basically clueless about dd.
I know basically what it does, but I've almost never been interested in
accessing storage devices at the block level. The whole thing about
File Systems is they do that job for you.

Post by Joe Davison
It's a complex evolving system.

I don't believe it is evolving all that fast, it seems to be more
stagnant than you suggest. It relies on volunteers for any change at
all.
About a year or so ago, there was a big flap that they were finally
going to update the Lisp underpinnings of Emacs, i.e. to create a
modern version of Emacs that used Lexical scoping in its Lisp,
instead of the old fashioned dynamic scoping.
The aim was to make the Lisp language within Emacs more modern and
usable, like all modern Lisp languages are.
That effort stalled out, so the Lisp within Emacs is just as
old-fashioned and outdated as ever.

Evolution doesn't happen overnight. The use of Unix is evolving faster
than the guts of the operating system or major applications -- so which
commands are relevent is what's changing. For instance, dd is a relic
from the past that very few people actually have any need for. At this
point you could be close to Guruhood on it's use, especially compared to
90% of unix users.

And that's the way it is with many of the commands -- the people who
have a use for them learn how to use them, the rest may not even know
they exist -- even if knowing would greatly simplify their lives. But
then I probably have neighbors on my block who could save me much work
if I only knew I should ask them XXXXX.

C'est la vie.

Post by Joe Davison
Learning to use grep/egrep/fgrep is like almost anything else worth
learning -- you have to try and fail and try again. Unfortunately,
that group of tools is no longer as useful as it once was, because
we're moving away from line oriented ascii files with '\n' line
terminators. It's still great for programmers, but if you do most
of your writing with a modern word processor, it's just nowhere near
as useful as it was.

I am confused. Are you saying that the regular search tools in a
modern word processor can do as good a job of searching as grep can?

Better in some cases -- but generally they only search in the open
document, and they may or may not take regular expressions. But your
modern word processor generally does not work with ascii files -- they
use proprietary formats that they know about and grep does not.

Open a new document in MS Word or some other favorite word processor.
Write a 10 line note and save it in the native format called MyTestFile.doc
Make sure you use the word "globular" at least 10 times. Use the
built-in search function to find those uses.

Now, open the terminal, cd to the appropriate directory and try
grep -i globular MyTestFile

It's probably won't be all that helpful, if it works at all.

Now open the file with the word processor and "Save As" MyTestFile.rtf
in (Microsoft) Rich Text Format.
grep -i globular MyTestFile.rtf

That might find the words, but there'll be lot of other funky stuff
including '{\' and all like that.

Now open it again with the word processor and "Save As" MyTestFile.txt
in "Text with line breaks" mode.
grep -i globular MyTextFile.txt
will probably find the lines.

The point is that grep is aimed at line oriented text files written in
ascii -- wonderful for 1968 - 2001 or so. But we've moved beyond
ascii. Ascii was 8 bit characters. OS X is designe around Unicode --
where characters are often at least 16-bits. Turns out the
Scandenaveians wanted to be able to use their whole alphabet -- and so
did the russians -- and sometimes they wanted to do both. grep was
designed for a different world.

Don't get me wrong, it's a wonderful tool, but you need to know it's
limitations and/or it needs to evolve.

Post by Joe Davison
...<heavily snipped>...simply don't want to learn the background
needed to understand the answer -- they just want the answer
stated so they can understand it.

Not so radically. I certainly agree that learning Unix these days
requires one to know much more than than is really desirable. However,
there are certain basic things that you absolutely must know or you have
almost no hope of learning to use Unix at the command line.

For instance, one of the most useful tools available at the command line
is how to use '|' to combine commands, but if you don't want to learn
about the unix file system and files as streams of characters, it's not
going to be easy. You probably have learned that one, at least I hope
so. Here's a test:

echo ha | tr a i >theAnswer

Without actually trying it first, do you know what that's doing?
Forget, for the momement the details, let me replace it with a gibberish
command line that illustrates my question better:

foobar ha | razzamatazz i a > theNextAnswer

If you knew what "foobar ha" did and what "razzamatazz i a" did, would
you know what the command line did?

That's where the power in the command lies, not in the individual
commands.

The command you need to understand to know what the '|' and '>' do is
the shell(1) -- probably bash(1) if you're using the default shell.

Basically "Learning Unix" means "Learning the Shell". But to do that,
it really is necessary to understand what a process is and the basics of
the file system.

Once you know the basics of bash(1), looking up echo and tr and hooking
them together is relatively easy.

Post by Mark Conrad
Examples of usage are much more valuable than pages and pages of
arcane background.

Absolutely correct. But the arcane background is often needed to
understand the example. Didn't you have to learn the arcane background
to use dd? How many thousands of examples would the manpage have
needed to accidentally hit the one you needed for your use?

Post by Mark Conrad
Examples are noticably absent from the man pages, which makes the man
pages almost impossible to understand.

Theya culpa! as the catholics don't say.

Those nasty developers should be shot at dawn for not properly
documenting their work. Unfortunately shooting them won't improve the
manpage.

Post by Mark Conrad
I will concede that _in_ _some_ _cases_ is is absolutely
essential that background basics be understood.

... fine example deleted

Post by Mark Conrad
In other words, showing by example how "define" is made, in Lisp.

Great, but the guys who wrote that were not developing lisp, they were
developing a text book to teach people about lisp.

Unfortunately, most companies don't hire people to write manpages
designed for people who don't already know how to use the system. They
hire programmers to develop tools other experts can use and force the
programmers to write the manpage so the other experts can make use of
the tool the company paid them to develop. If the programmer takes the
time to write a manpage that can be understood by someone who's never
used unix, they'll get fired for not doing their job, and the experts
who need to use the tool will bitch an moan about all the extraneous
crap they have to read to get to the info they need to do their job.

That's why there are all those books in the computer store about each
individual application that runs on Macs/Windows. The people who write
those books do get paid to write the book - if they do a good job.

Unfortunately, most people who don't know anything about Unix won't pay
for the kind of book you're asking for. Some of them will, however buy
the books people keep recommending.

Post by Joe Davison
I'll even do individualized tutoring at a comparable rate.
In fact, I've spent time in this newsgroup
doing it for free, as you may recall.

...and I complement you for that. Likely, when you yourself started
with Unix, others probably helped you for free.

Actually, when I started we were all novices, unix was new and almost
all we had were the manpages -- plus a couple of tutorials that are
still on the web. But I was a grad student, and most of the others were
undergrads, and we were happy to claw our way through the manpages
bitching and moaning about how shitty they were because of the neat
things we could do once we figured it out.

Like you, I got tired of that after awhile but by then I already knew
enough that I seldom needed to fight my way through new manpages because
I could write my own C/Shell program easier than learning to use the
existing one (or even finding out it existed) ...

Then I got tired of that and bought a mac... And it wasn't long before
I wished it ran Unix. And now it does, halelujah!

Post by Mark Conrad
...although I hear from many that help was not all that easily come
by, compared to the help that is available today. (Google, etc.)

True enough. Creating jillions of people who think the manpages suck
will sometimes produce a few who will stop bitching and write a tutorial
or a better manpage. If you happen to feel so inclined, I recommend
going to http://www.gnu.org and volunteering.

As they say, Life sucks, and then you die.

Almost nobody does what we all know they should have!

joe

Mark Conrad

2005-04-11 08:42:50 UTC

In article <***@Jupiter.local>, Joe Davison
<***@comcast.net> wrote: buncha good stuff :)

So much of value in your posts, thanks very much.

Gadd, I hate one-liner posts, they just don't have anything of value in
them.

...except maybe that one-liner in the old movie where the actor in the
movie answered a question by saying "Rosebud".

I forget the details, but at the time it amused me.

Post by Joe Davison
For instance, one of the most useful tools available at the command line
is how to use '|' to combine commands, but if you don't want to learn
about the unix file system and files as streams of characters, it's not
going to be easy. You probably have learned that one, at least I hope
echo ha | tr a i >theAnswer
Without actually trying it first, do you know what that's doing?

No, I am ashamed to say. But I _do_ know that I am really hurting
myself by not knowing how to use piping and re-direction.

When I get around to learning those concepts, I certainly won't do it
by "learning the bash shell" from the man pages. To me, that frontal
assault is loaded with frustration.

As you yourself said, the man pages are designed by programmers, for
programmers, not for novices like me.

Instead, I will beat the bushes of my limited library of Unix books,
looking only for _examples_ of piping and re-direction.

I will also use Google, looking for _examples_ of piping/re-direction.

When I was learning how to use the dd command for backup/restore
purposes, I wasted days/weeks in my local B&N bookstore, browsing those
foot-thick Unix books for details about dd.

Total waste of time. Only way I ever did learn how to use dd for the
intended purpose was from the Unix experts in these NGs.

About dd versus ar - - -
BTW, I tried a "man ar" in Terminal, but it said there was no man
entry for ar. I am using bash on OS 10.3.8

About grep -
Thanks for the detailed answer to my question concerning whether or
not grep is "obsolete" among modern word processor programs.
Now I understand what you mean when you said grep has limited uses
in today's modern world.

About needing to learn Unix background - - -

Post by Joe Davison
Didn't you have to learn the arcane background to use dd?

Not really. (at least I don't think I "learned Unix background")

Using psuedo code:

dd [path to OSX partition]
[path to backup file]
[size of block to copy, in bytes]
[number of blocks to skip]
[number of blocks to copy] <space> ; <space>

The actual dd command corresponding to above psuedo code:

dd if=/dev/rdisk0
of=/Volumes/Util-4/Backup/Bak
bs=524288
iseek=0
count=1000 ;

That dd command (above) backs up the first big chunk of my OSX
partition, it is followed after the last semicolon by code to backup
the _second_ big chunk of my OSX partition: (below)

dd if=/dev/rdisk0
of=/Volumes/Util-4/Backup/Bak2
bs=524288
iseek=1000
count=1000 ;

...and so on until as many big chunks are backed up as is necessary in
order to back up the entire OSX partition.

I skipped some important details for brevity, but you see the main idea.

It is a very robust backup scheme. To give you an idea of _how_
robust, I could destroy the three partitions on my internal drive, by
partitioning the drive as one big partition.

Using my dd backup files, I can restore the original three partitions
in five minutes, with my OSX partition its original size of exactly
21,474,836,480 bytes. (exactly 20 GBs)

About the shitty man pages - - -

Post by Joe Davison
But I was a grad student, and most of the others were undergrads,
and we were happy to claw our way through the manpages
bitching and moaning about how shitty they were because of the neat
things we could do once we figured it out.

...and I continue the bitching and moaning, knowing all the while it
will do no good, but it makes me feel better.

Post by Joe Davison
As they say, Life sucks, and then you die.

- - - and - - -

Post by Joe Davison
Almost nobody does what we all know they should have!

I would like to add some comments to the above pearls of wisdom.

Some of us old geezers get a guilty conscience near the end of our
lives. That in turn motivates us to do one or two of the things that
need doing in this world.

If I was running the world, I would deliberately treat every old fart
with as much dignity, respect, help, courtesy, support, as I could
possibly muster. I would treat them so nice that they would cry with
gratitude.

They would not know, of course, of my ulterior motive, which would be
to give them a giant sized guilty conscience for what bastards they
were during their life.

I bet most of them would buckle right down and do the things that the
rest of us just do not get around to doing, like a rewrite of the man
pages for the benefit of Unix novices.

Even now, despite the fact that a lot of other countries treat their
older population a lot better than we do, the old people in the U.S.A.
do a heck of a lot more volunteer work than their younger counterparts.

Very priceless, that volunteer work, about the only way to get things
done that would not get done otherwise.

In my case, I am voluteering all my meager resources to encourage the
use of Macs in northern California. There is a severe misbalance up
here, almost everyone uses PCs.
(much more so than in other parts of California)

To my way of thinking, PC users are just hurting themselves by
essentially ignoring the Mac altogether.

Worse yet, Apple shows no interest in these rural areas, because it
just doesn't pay them to devote any resources here.

Several years ago there was a store here named "Connecting Point", and
they had another store about 70 miles from here. They sold new Apple
computers, software, printers, etc. Interest in Macs developed, lots
of people shopped there, you could not tell that store from a
legitimate Apple store - - - in fact, I thought it was.

Apple brought a lawsuit against them, forced both of them to close.

Ever since then, interest in Macs has severly declined in this area.

What really bugs me is that a fair percentage of Mac users see the
advantages of running both Macs and PCs, but almost no PC users, by
comparison, see any advantages to using Macs.

Mark-

Chris Moore

2005-04-07 16:53:28 UTC

In article <060420052125148282%***@invalid.com>, Mark Conrad
<***@invalid.com> wrote:

<big clip - summary: trouble understanding security>

See if this site describes it in an easy to understand fashion:
http://netsecurity.about.com/cs/compsecurity101/index.htm

Post by Chris Moore
I'd be glad to help. What specifically are you having trouble with?

Okay, you asked for it. ;-)

Specifically it was about Little Snitch but go on.

Post by Mark Conrad
Having simpleton senile logic, I do not understand simple terms like
"server", "host", "client", etc., which is probably apparent by my
previous remarks. These confusing terms are bandied around in
computer literature, and never fully explained.
For example, Apple's remote control application, which is named
"Apple-Remote-Desktop",

Ok, we'll tackle server/host/client from within these confines. I use
ARD (you knew that) so hopefully it will be easy.

Post by Mark Conrad
can not do a bunch of stuff that TB2 can do.

That may be, I don't know anything about TB2. Perhaps I'm biased but
I'd be willing to bet there's more ARD can do that TB2 can't. Do you
have an example? I'll toss one out for you. Can TB2 install the latest
OS update (or any other software) to all managed computers
simultaniously? (Note: And the part that impresses me most, if it takes
10 minutes to do one computer it will take 10 minutes to do 50)

Post by Mark Conrad
I am told that OS X already has a "client" ARD included free as part of
OS-X.

The 'client' is free. It is included and preinstalled with Panther and
must be installed sepearatly on OS 9.0 through 10.2. The installation
software for these systems comes with the Administrator software. ARD
can not control computers that do not have at least Mac OS 9.

Post by Mark Conrad
Now the "administrative" (server?) part of ARD has to be purchased,
for $200.

True, the ARD Administrator must be purchased. I'm not so inclined to
consider it a server though. A server being something that responds to
client requests. I have a file server that holds files, we have web and
email servers, we have dhcp and print servers. In all cases the client
initiates the communication. "I'm here, assign me an IP address."

Post by Mark Conrad
This administrative part of ARD is installed on only _one_ computer,
I am told. That one computer can "control" many ordinary OSX
machines.

If you purchase more than one copy of the Administrator software you
can install it on more than one computer. We have several campuses,
each with their own copy. My first day on the job I was introduced to
the software at the Chicago campus, and we viewed the machines at my
campus some 20 miles away.

Post by Mark Conrad
However ordinary OS X machines can _not_ control the "administrative"
computer, like they would be able to do if they were using TB2.

Correct.

Post by Mark Conrad
So my question is, which of the computers in an ARD network are the
servers, and which computers are the clients.
Are they all clients?

Yes

Post by Mark Conrad
Are they all servers?

(Administrators) No.

Post by Mark Conrad
Are they all both clients
and servers? (likely that last is correct)

A machine can be both, client and administrator, provide you purchased
an ARD Administrator for each machine. In my own setup I have one
Administrator machine which is not set up as a client, and 60 clients,
which do not have the Administrator software installed.

Post by Mark Conrad
My present understanding of what a "server" is, is merely a computer
that "serves" or "makes-available" something requested by a "client".

That's my understanding as well.

Post by Mark Conrad
I am probably getting "server", "client", and "controlling-computer"
all mixed up with each other.
In other words, "controlling-computer" probably has nothing at all to
do with whether a computer is a "server" or a "client".

I would agree.

Post by Mark Conrad
All very confusing to me, hinders me when I run across these terms
while I am trying to learn OS X advanced security stuff.

That web site I pointed to earlier may help.

Mark Conrad

2005-04-08 11:10:12 UTC

Post by Mark Conrad
Having simpleton senile logic, I do not understand simple terms like
"server", "host", "client", etc.

Ok, we'll tackle server/host/client from within these confines. I use
ARD (you knew that) so hopefully it will be easy.

Thanks, I found your post very enlightening, especially the part about
ARD capabilities.

Post by Mark Conrad
...ARD can not do a bunch of stuff that TB2 can do.

Sounds to me that ARD is a lot better than TB2 for "managing" large
groups of Macs simultaneously, doing stuff like updating all their
software at once. TB2 can only update one at a time.

About TB2 -

Post by Chris Moore
Do you have an example?

Thought you would never ask ;-)

1) Can create QT video of any computer's desktop display, however total
size of QT movie is limited to 2 GBs. That means that a new QT movie
would have to be started, causing a brief interruption in a long QT
movie record.

2) Any computer in a TB2 network has full control of just how much the
other computers in the network are allowed to do. Anything from no
access at all, to full access, or anything in between.

3) Full duplex voice over same TB2 connection (broadband only)

4) Unlimited number of small "live" windows of remote computer's
desktop., such windows can be as small as one inch square. One click
and any small window is full screen size. I think ARD is limited to
six small live windows.

5) Ability to run on XP, NT, 2000, and a couple of other "modern" PC
OSs, however can't run on older PC OSs or DOS.
VNC seems to be able to run on the most platforms.

6) Very tight security. ARD also has tight security. VNC still has
internal vulnerabilities. VNC is reported as being slower than even
PC-Anywhere, which in turn is slower than TB2.

7) Simple drag and drop of files between live desktop screens.

8) Ability to restart remote computers, even PCs, while still retaining
full control of them. With auxillary hardware, even a frozen Mac can
be restarted, remotely.
A completely dead Mac with hardware problems, n-o-o-o.

9) Ability to install TB2 into a distant Mac which does not already
have TB2, _and_ the ability to fully configure the new TB2 app'
without losing control of the Mac. (Mac only, won't work with a PC)

10) Full control over number of screen colors, from none to millions.

11) Full support for file permission system, Fast-User-Switching, and
almost everything else on a Mac, with the exception of no audio in or
out on the remote Mac or PC. Even running Terminal sessions on the
remote Macs works fine.
I would imagine that low level stuff like Single-User-Mode will not
work, however.

Okay, in summary I think that all the available remote control programs
have their strong points and weak points. It is a shame that we have
to "pick" just one, in order to save money and disk space.

Worse yet, these programs won't talk to each other.

If I were "administering" large numbers of Macs, I would pick ARD.

If I wanted to operate on the maximum number of OSs, I would pick VNC.

If I wanted Mac and PC cross-platform personal computer usage with a
goodly amount of features, speed, and easy install/setup/operate, then
I would pick TB2.

'course, it would be ideal to have all three of the above RC app's on
my Mac, if I had the money and time to play with them.

BTW, thanks for clarifying the terms "server" and "client", especially
the part about a server being something that responds to client
requests.

Mark-

Walter Bushell

2005-04-22 03:25:17 UTC

Post by Chris Moore
You seem to have this 'all or nothing' approach to things. No one ever
went from zero to genious in one step.

Well I am getting somewhat discouraged. (with myself)
Like someone here once said, I have been at this for some time now,
without hardly anything to show for it.
(ever since OS 10.0, whenever that was)
I can't claim newbie status anymore, however every time I hear Unix
experts out there discussing any subject, I feel lost because I can't
follow their discussions at all.
(the recent SSH thread, for example)
What happened to the concept that computers were supposed to make
things simple for us?
Excuse the bitchin'. I realize as much as anyone that to use the
present OSX to full advantage, that one has to bury one's self in Unix
for 20 years, learning slowly by osmosis, because there is _no_ easy
way to learn Unix, at least as far as learning how to use Terminal
commands is concerned.

I had it in the OS 9 days. Default configuration will probably be
adequate for starters. As you learn more you can configure it more.

Gadd, I hope that I will be able to configure it more.
I hope I can learn enough by fiddling with NetBarrier that I will be
able to create my own "rules" for that firewall.
The main reason I went with NetBarrier instead of OSX's built-in
firewall is because Intego inc. told me that they would help me over
the rough spots, as far as setting it up and configuring it.
From what I have read so far about creating firewall rules, one has to
go through a complex juggling act involving the "order" of the rules,
also rather the rules are "general" or "specific", and a whole mess of
other considerations about rules.
Very easy to mess up, IMO.

That 'garbage' has some merit.

Oh I agree with that, to the extent that crackers have not _yet_
considered it worth their while to bother OS X users, especially
considering how easy it is to "crack" a Window's OS.

Post by Chris Moore
...<severe snipping>...the basic GUI Mac security measures
will prove more than adequate for your needs.

I do not want to fall into that trap, because I believe that attitude
could cause me a very rude awakening.
I prefer to err heavily on the side of "too much protection".
Anyhow, my attitude is a heck of a good excuse for learning a lot more
about security. ;-)

Post by Mark Conrad
A) "The Happy Hacker" by Carolyn P. Meinel 1999
(general Unix security horror tales)

Not familar with it.

That book, even though old, (1999) really opened my eyes to the sort
of damage that crackers can do to a Unix user. Very scary.

Post by Mark Conrad
"Mac OS X Maximum Security" 2003 ISBN 0-672-32381-8
(747 pages on general Mac security issues)

This is a great book if your administering a network or a server. It's
a little over the top for a home user, though I imagine there are some
tidbits in it worth knowing.

Yes indeed, that book is generally great on important details.
TB2 by its very nature is both a "network" and a "server", (or "host"
if you prefer that term} - - - a TB2 computer can even be a "client" at
the same time that it is being a "server".
For example, a TB2 "server" computer named "Foobar" could be serving a
file requested by a client computer named "Jason", at the same time as
"Foobar" is acting as a client by requesting a file to be served by
"Jason".
In other words, the two computers "Foobar" and "Jason" are both acting
like servers and clients, simultaneously.
The two files pass each other in transit, both files going in opposite
directions. Convoluted, isn't it.

Post by Chris Moore
I'd be glad to help. What specifically are you having trouble with?

Okay, you asked for it. ;-)
Having simpleton senile logic, I do not understand simple terms like
"server", "host", "client", etc., which is probably apparent by my
previous remarks. These confusing terms are bandied around in
computer literature, and never fully explained.
For example, Apple's remote control application, which is named
"Apple-Remote-Desktop", can not do a bunch of stuff that TB2 can do.
I am told that OS X already has a "client" ARD included free as part of
OS-X.
Now the "administrative" (server?) part of ARD has to be purchased,
for $200.
This administrative part of ARD is installed on only _one_ computer,
I am told. That one computer can "control" many ordinary OSX
machines.
However ordinary OS X machines can _not_ control the "administrative"
computer, like they would be able to do if they were using TB2.
So my question is, which of the computers in an ARD network are the
servers, and which computers are the clients.
Are they all clients? Are they all servers? Are they all both clients
and servers? (likely that last is correct)
My present understanding of what a "server" is, is merely a computer
that "serves" or "makes-available" something requested by a "client".
I am probably getting "server", "client", and "controlling-computer"
all mixed up with each other.
In other words, "controlling-computer" probably has nothing at all to
do with whether a computer is a "server" or a "client".
All very confusing to me, hinders me when I run across these terms
while I am trying to learn OS X advanced security stuff.
Mark-

Yes, and the most important thing in eating an elephant, don't let her
get on top.

--
Guns don't kill people; automobiles kill people.

Walter Bushell

2005-04-22 03:27:42 UTC

In article <060420052125148282%***@invalid.com>,
Mark Conrad <***@invalid.com> wrote:
<snip>

<snip>

Server and client have opposite meanings in different systems! Host is
what the priest hands out during mass.

--
Guns don't kill people; automobiles kill people.

Walter Bushell

2005-04-22 03:23:50 UTC

In article <060420051922527727%***@newsgroup.INVALID>,
Chris Moore <***@newsgroup.INVALID> wrote:
<snip>

Post by Chris Moore
That 'garbage' has some merit. If your computer holds a database of a
couple of tens of thousands of valid credit card numbers then I'd be a
little paranoid too. High level hackers will be taking aim. If your
worried about your tax returns falling into the wrong hands, the basic
GUI Mac security measures will prove more than adequate for your needs.

<snip>

Well maybe not, if you are doing quadruple (or higher order)
bookkeeping, on a scale that would interest the Infernal Revenue Service.

--
Guns don't kill people; automobiles kill people.

Davoud

2005-04-07 02:20:30 UTC

Post by Mark Conrad
Is there anyone out there over 80 years old who can explain "real" OSX
security to me, in simple terms, without resorting to "Terminal Hell"
techno-speak...

Read the Mac news services and this forum every morning *before* you
check your e-mail. That way you'll likely learn of the first exploit or
malware before it affects your system. Disclaimer: I am under 80 years
of age.
Ah, there's the problem. Stick with the Lassie books and similar light
fare. Some suspense, but you know going in that everything will turn
out OK.

Davoud

--
usenet *at* davidillig dawt com

Mark Conrad

2005-04-07 19:04:16 UTC

Post by Davoud
Ah, there's the problem. Stick with the Lassie books and similar light
fare. Some suspense, but you know going in that everything will turn
out OK.

You got that right. When one is heading for the last roundup, one
concentrates on the really important things in life, like watching
Loony-Tunes on TV, and old M.A.S.H programs.

I am even thinking of junking my membership in the professional
computer societies I belong to, the IEEE, ACM, AAAI.

All that fluff was useful when I was younger and needed to impress
someone, but now it is a pain in the neck to listen to those eggheads
yapping for more funding for their pet "projects".

Now I can sit back and insult anyone I want to, without having to worry
about it getting back to my employer.

Post by Davoud
Disclaimer: I am under 80 years of age.

Aha, then you must be one of those young smart-alecky whippersnappers
who are only 65-years old, or so.

When you get my age, you will have a whole different outlook on life.

Mark-

Jeff Wiseman

2005-04-07 04:14:42 UTC

Post by Mark Conrad
Is there anyone out there over 80 years old who can explain "real" OSX
security to me, in simple terms, without resorting to "Terminal Hell"
techno-speak?
By "real" security I mean the realistic view that OS X _can_ be
broken into - - - not the garbage that is constantly spouted in this NG
that OS X is somehow immune to breakin by a skilled cracker.
Here is the "Lack of Progress" that I have suffered so far, in my
futile thrashing around, trying to get a reasonable level of security
for myself. (I run TB2 so I _need_ added security)

OK, for a starter, turn on the firewall that comes with OS X,
turn off all of the services and internet sharing if they are on,
and then run the security tests at:

http://security.symantec.com/sscv6/default.asp?langid=ie&venid=sym

and

http://scan.sygate.com/

That should make you feel a lot better and in a more balanced
state of mind to deal with this stuff (usually lots of green
lights and good feelings there when you are running a mac :-)

Now, are you running TB2 from outside your home to get to your
home or what is the sit'ation there? If you can get all your
machines inside a local network with a hardware firewall at its
entrance, you could make your system plenty secure and all of it
can be done without command line usage :-)

--
Jeff Wiseman
to reply, just remove ALLTHESPAM

Zaphod B

2005-04-07 07:26:28 UTC

Post by Jeff Wiseman
Now, are you running TB2 from outside your home to get to your
home or what is the sit'ation there?

Search google-groups for Mark Conrad. There have been several _long_
threads discussingg TB2 deployment and security up, down and across.

--
/Z

Mark Conrad

2005-04-07 19:04:10 UTC

Post by Jeff Wiseman
Now, are you running TB2 from outside your home to get to your
home or what is the sit'ation there?

Several varied situations, which I will list:

1) Running TB2 "on the road" using a HP PC model N5425 with XP Pro
operating system, using latest TB2 for a PC, namely version 8.0.0.1113
- - - to access my Mac at my house - - - Mac runs OS 10.3.8 and latest
TB2 ver' 8.0.1

The remotely operated Mac might be doing rather exotic chores, like for
example contacting another Mac TB2 user in Hilo, Hawaii - - - or
installing/configuring TB2 into another Mac which does not have TB2.

The only reason I sometimes go on the road with a PC is because the PC
has a much better speech recognition app' than is presently available
for a Mac - - - and at times I get "backed up" with dictation chores.

2) Run my Mac powerbook either from my house or from the road, hooking
up to private and public networks of mixed PCs and Macs. Some of those
Macs might be "low-budget" Macs belonging to poor school districts who
are still using old legacy Macs running OSs like 8.6 - - - a student or
teacher in that poor school would be able to fully remotely control the
lastest Mac running Tiger, for example, right from their old Mac. (or
PC)

3) Running TB2 in a mutual learning/teaching/consulting situation,
where the remote user might be either the teacher or the student, or a
peer with the same level of knowledge. In such an instructional
situation, the TB2 users have to be prepared to control other Macs or
PCs, or be controlled by those Macs or PCs - - - such
instruction-oriented use would include TB2's ability to create
QuickTime movies of the screens of any Mac or PC in the TB2 network.

4) Do fully automated operation and maintenace of remote computers,
including backups and restores, recovery from "freezes", etc. - - -
such computers might be "headless", might have CD jukeboxes.

Summary - The mere fact that PCs are in the mix calls for somewhat
advanced security measures, like using Public Key Authentication
instead of passwords.

Another really big problem is to keep from getting sued someone. Local
officials could easily hold a Mac user "responsible" for any imagined
damage he creates by remote operation of computers.

The insurance companies get their pint of blood and your firstborn
child, when you are more-or-less forced to get costly insurance
coverage.

Post by Jeff Wiseman
That should make you feel a lot better and in a more balanced
state of mind to deal with this stuff.

Hmmph, if it were only that easy.

Mark-

Jeff Wiseman

2005-04-08 19:25:02 UTC

Post by Jeff Wiseman
Now, are you running TB2 from outside your home to get to your
home or what is the sit'ation there?

1) Running TB2 "on the road" using a HP PC model N5425 with XP Pro
operating system, using latest TB2 for a PC, namely version 8.0.0.1113
- - - to access my Mac at my house - - - Mac runs OS 10.3.8 and latest
TB2 ver' 8.0.1
The remotely operated Mac might be doing rather exotic chores, like for
example contacting another Mac TB2 user in Hilo, Hawaii - - - or
installing/configuring TB2 into another Mac which does not have TB2.
The only reason I sometimes go on the road with a PC is because the PC
has a much better speech recognition app' than is presently available
for a Mac - - - and at times I get "backed up" with dictation chores.
2) Run my Mac powerbook either from my house or from the road, hooking
up to private and public networks of mixed PCs and Macs. Some of those
Macs might be "low-budget" Macs belonging to poor school districts who
are still using old legacy Macs running OSs like 8.6 - - - a student or
teacher in that poor school would be able to fully remotely control the
lastest Mac running Tiger, for example, right from their old Mac. (or
PC)
3) Running TB2 in a mutual learning/teaching/consulting situation,
where the remote user might be either the teacher or the student, or a
peer with the same level of knowledge. In such an instructional
situation, the TB2 users have to be prepared to control other Macs or
PCs, or be controlled by those Macs or PCs - - - such
instruction-oriented use would include TB2's ability to create
QuickTime movies of the screens of any Mac or PC in the TB2 network.
4) Do fully automated operation and maintenace of remote computers,
including backups and restores, recovery from "freezes", etc. - - -
such computers might be "headless", might have CD jukeboxes.
Summary - The mere fact that PCs are in the mix calls for somewhat
advanced security measures, like using Public Key Authentication
instead of passwords.
Another really big problem is to keep from getting sued someone. Local
officials could easily hold a Mac user "responsible" for any imagined
damage he creates by remote operation of computers.
The insurance companies get their pint of blood and your firstborn
child, when you are more-or-less forced to get costly insurance
coverage.

Post by Jeff Wiseman
That should make you feel a lot better and in a more balanced
state of mind to deal with this stuff.

Hmmph, if it were only that easy.
Mark-

Well, that appears to be outta my territory. Life is a lot easier
if you have your own contained network. I've not dealt much with
going outside that domain.

Perhaps some kind of VPN arrangement? Many inexpensive consumer
network routers/firewalls come with these capabilities now.
Again, it may all be configurable from the network products
themselves.

--
Jeff Wiseman
to reply, just remove ALLTHESPAM

Mark Conrad

2005-04-09 17:11:59 UTC

Post by Jeff Wiseman

Post by Jeff Wiseman
Now, are you running TB2 from outside your home to get to your
home or what is the sit'ation there?

Well, that appears to be outta my territory.

Yep, that is why I replied to you in such detail concerning my security
requirements while using Timbuktu. (TB2)

Security for me would be a lot simplier if I used TB2 in a restricted
fashion, where the participants merely observe each other's screens, or
where I allow them to have access to just certain files or folders.

In those cases, the regular security features of OS X and TB2 would be
more than adequate.

As soon as we open up TB2 and allow others to actually control our
Macs, then the whole situation changes.

That is the main reason why remote control app's of any sort are not
used more, by either Mac or PC people.

Oh, TB2 _can_ be run in such a manner that it would by "safe" to let
a stranger control a Mac, however a lot of precautions would have to be
taken.

Just for beginners, all sensitive user files on the Mac would have to
be removed or encrypted, so they could not be read.

If the stranger turns out to be a bad guy, he might still be able to
zap my Mac, but that doesn't bother me at all. It only takes minutes
for me to restore my Mac to its previous condition.

Post by Jeff Wiseman
If you can get all your machines inside a local network with a
hardware firewall at its entrance, you could make your system
plenty secure and all of it can be done
without command line usage :-)

I do a variation of that. I connect my Macs/PCs with Ethernet cables
in order to check out my setup, then I actually try to mess them up,
one to the other.

If I can't succeed, then I am reasonably sure that the usual
kiddie-crackers won't be able to succeed either, when I get around to
changing over from Ethernet to regular Internet operation.

Last night I succeeded in _remotely_ installing TB2 into one of my
Macs. All that is necessary was that the remote Mac has to have its
"Remote-Login" turned on. (in Sharing pane of System Preferences)

It was easy, I installed TB2 remotely. Did not even have to
"configure" it, did not have to restart the remote Mac.

After installation, I had complete use and control of the remote Mac,
just as if I was sitting at its keyboard.

This feature would be handy for those users who have family members
with Macs in distant cities. It would allow them to help their family
members with computer related problems.

This remote install feature only works Mac-to-Mac, I can't
remote-install TB2 into a PC.

Mark-

Joel Farris

2005-04-09 19:48:45 UTC

Uhh, Mark, you opened the front door, tossed the keys onto the porch, and
posted a welcome sign on the front lawn, and now you're worried that
someone might break in and steal stuff?

You should prolly close the TB2 front door if you want to sleep better at
night. It seems to me that anyone who opens their computer up to full
remote access by anyone with the properly guessed credentials will do well
to not have ANY valuable info on that machine. A second compy for daily
personal use is recommended in your situation.

--
Joel Farris | AIM: FarrisJoel

** Their Web. Your Way. http://getfirefox.com **

Mark Conrad

2005-04-10 11:02:28 UTC