From: adam@address.invalid
Moe Trin wrote:
> On Sun, 31 Mar 2013, in the Usenet newsgroup alt.os.linux.mandriva,
> in article , Adam wrote:
>> helot [...] at two different hotspots, the hospital and the rehab.
>
> As you get time to play more, you'll find that it really isn't that
> difficult to get the links up/running.
Now I know it's possible, just a matter of refining the procedure. I
think I'm about ready to start bringing it to McDonald's, DCC, et al.
> 802.11a is essentially the same as 802.11g (up to 54
> Mbits/sec) but is usually less interference prone. There are two
> faster protocols (802.11n and 802.11ac), but they're less common.
My equipment (router, eris's PCI card, helot) has some subset of
802.11a/b/g, except stolid's integrated 802.11 b/g/n which I've never
enabled as I assume wired is faster. It sounds like things are
realistically about as fast as I can get them, so there's no reason to
buy any new equipment.
[helot netstat]
My fault, I don't think that was everything. Here's what I get at home:
[root@helot ~]# netstat -antpu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1785/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1646/cups
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1865/master
tcp 0 0 :::22 :::* LISTEN 1785/sshd
tcp 0 0 ::1:631 :::* LISTEN 1646/cupsd
udp 0 0 0.0.0.0:631 0.0.0.0:* 1646/cupsd
udp 0 0 0.0.0.0:68 0.0.0.0:* 2014/dhclient
[root@helot ~]#
> Essentially safe enough.
Sounds like all that's still true, and still "safe enough".
> in theory the bad guys could advertise another
> printer outside, and if you actually told your printing setup to try
> to use that... I'm not sure where you'd be able to pick up your
> print jobs... maybe it's down the hall or in the other building ;-)
At IBM, I wrote a program to keep track of employee names, badge
numbers, and operator IDs. IIRC invoking "print" gave the message
"Please pick up your printout tomorrow from Building 330, room
[whatever]" where the system line printer was. I gather there's no
consistent way to print when I'm at a hotspot, although a few may have a
separate SSID for a printer.
Now that I seem to have gotten the basics down, I've decided to do a
clean install of (a slightly newer version of) CentOS on another
partition, avoiding all the things I had to remove from the current
installation. I was planning on two users (besides root), "adam", who
has no web access, for writing and system configuration (su and sudo),
and "web" which will have several browsers and lots of plugins for
websites, but NO stored passwords. (Well, maybe an overgrown text file
like yours for passwords.)
Another thing I have to look into is whether it's possible to encrypt
all of, and only, the partition /mnt/accounts, and have it readable from
more than one distro, without slowing things down too much. I don't
think hardware/BIOS passwords are necessary.
[small surge protector]
> they aren't that expensive, and might help in the off-chance
> of a nasty power spike.
Staples /does/ have a few, so I'll probably get one.
[new location and method for offsite backups]
> "What is your disaster scenario?" What are you trying to protect
> against?
I think my biggest concern is actually the discs themselves (the more
important ones) going "bad". Once I bought some burned music CDs, and
within five years they were unplayable (no damage on my part). I
suppose the best solution to that would be to copy them to new discs
every 2-4 years and/or copy them to one or more external USB drives,
perhaps one offsite.
Second would be the ability to restore specific files from yesterday's
or last week's nightly backup, and third would be failure of the
internal and maybe external HDs. The nightly backups are tarballs on
the external HD. Every week I also back up to a DVD+R (I use five and
rotate them), kept on my computer desk.
> The on-site for you is much easier now, having two functional
> systems, where you can copy data from one to another.
What's the advantage of that over an external DVD or HD?
> I've actually stopped using CDs/DVDs as backups
> for the same reason I'm not using tape or floppies. I can buy external
> media such as USB drives that hold more (Best Buy had 128 GB USB drives
> for $80 as one example) and can fit into a small fire-resistant box in
> the entry-way closet.
Or perhaps two of them, occasionally swapping the slightly out-of-date
one offsite with the current one at home.
> At least for the shorter term, you'll still have
> some storage capability with your father.
Yes, but I'll eventually need something else, and once I'm reworking my
backup routine I may as well switch to the "something else" at the same
time.
>> "Dynamic" would be my most recent backup tarballs, currently about
>> 500 MB nightly,
>
> You might be able to reduce that by using incrementals rather than full
> backups of important stuff.
The few times I've wanted to restore anything, it was just one file,
yesterday's or last week's version of something I unintentionally
clobbered, which would be a pain with anything other than a full backup.
I once tried differential (not incremental) backups for a week and by
the last day the differential was about 70% of the size of the full backup.
> The data (essentially /home/) now gets a monthly full
> backup, and daily and weekly incrementals.
Excerpt from /etc/cron.daily/zwieback.cron:
# list of directories and files for full, weekly, monthly backup
BACKUP_LIST="/home /mnt/accounts /root /etc /usr/local \
/var/lib /var/log /var/spool/mail /var/spool/postfix \
/boot/grub/menu.lst \
which includes everything under those. This is followed by a batch of
"--exclude=" for thumbnails, web caches, *.iso, and other files within
that list not worth backing up.
>> and I think one of the "free backup" sites might be adequate for two
>> or three recent ones of those, encrypted.
>
> More than one site - but use the same _encryption_ key for "identical"
> backups. (A recent discussion elsewhere: many encryption schemes can be
> cracked if the bad guy has access to multiple copies of the same data
> encrypted with _different_ keys - admittedly, "many" copies, but just
> the same).
I never heard of that, but I see the point.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
