LAN access while VPN is up

I don't know a lot about Samba either, other than it was trivial to install and configure, and has been absolutely reliable except when I've messed with the network - and I have a hunch the neighborhood cruft is implicated in prior odd behavior. This time I'll shut down the windoze boxes, renumber the network, restart Samba, then restart the windoze boxes - give it a chance to acclimatise before windoze starts yammering away at it.

Full images weekly, incrementals every 4 hours, monthly rotation - so I can roll back to anytime in the last month. Plus a zero-day full image on CD.

I'd have told them they were wasting their time, and would have to waste more obtaining a warrant if they wished to persist.

Ya can't win. Today he _bought_ an audio CD because he couldn't grab the music via P2P. I'd approve, but the damn disc autoruns DRM cruft that tries to patch windoze kernel-mode APIs to cloak itself - AKA a rootkit.

It didn't work - no music, and windoze couldn't read any disk in the drive afterward due to corrupted filter drivers. If it wasn't for Mark Russinovich's blog, I doubt I'd have figured out what happened:

formatting link
I rolled his system back to restore access to the cd drive, then used various unix tools to analyse the offending disc layout, pull off the audio sectors, and burn a standard CDDA audio CD. Now my son can listen to the music he paid for - and I'm thankful I don't reside in the US, so can't be prosecuted under DCMA for making a usable copy.

Sometimes it's hard to convince my kids they should pay for intellectual property usage rights...

Triffid

Reply to
Triffid
Loading thread data ...

Sheesh.

I wouldn't have found and resolved the Samba file permissions issue if I hadn't tested my backups, now would I?

The windoze boxes here are all running ancient SCSI disks, and most have suffered at least one disk failure. Ghost backups worked flawlessly in all cases - and again tonight when my son's system got screwed by defective DRM software (see my other post in this thread).

Triffid

Reply to
Triffid

Many thanks for a lot of very interesting background I wasn't aware of - which appears to position the 5GT as an oddball entry in the NS product line. Know how it came about?

Triffid

Reply to
Triffid

Sounds a bit overkill, but its certainly the right concept. Like most, we only do a nightly backup - mainly a bandwidth problem. All our users are on network file systems, and each file server has a dedicated backup channel. The other servers all have three NICs - one to serve over, one for admin use, and one for backups. The backup networks all lead to backup servers with extra drives as well as tapes (yes, we still use 'em).

I think in this instance, it was more a case of 'gloat' than anything else.

It's been on Usenet too. Did the disk have the CD trademark? I've heard that Phillips is complaining about the DRM stuff violating the standard that allows the use of that mark.

Is there not a Canadian law against computer tampering? I know there are several states down here that have such laws, and Sony is counting on the US federal law taking precedence over the state laws.

Reminds me of the 1950s when the popular radio stations used to put an annoying voice announcing the callsign at the end of each chorus for the first week the release of a new Top 50 song to discourage taping. 'WINS' in New York City and 'WKBW' in Buffalo used to drive me nuts that way. I imagine there were other stations pulling that trick.

s/my\\ kids/people/

Old guy

Reply to
Moe Trin

Might be a little over the top, but manageable. Full images are scheduled in the wee hours, and incrementals are typically well under a meg. The scheme consumes around 10GB per windoze box on the file server, which is backed up to tape biweekly. Tapes are a pain, but how else do you back up 200GB affordably, at home?

Nope, even the spot on the jewel case where the Phillips mark is normally embossed is a blank rectangle. This one was published by EMI, but they appear to have licensed the same cruft as Sony.

I believe so, but I'm not about to file suit and I doubt the police would show an interest.

The music industry here managed to shoot itself in the foot rather effectively a couple of years ago by convincing the government to collect a levy on all blank media and distribute the proceeds to artists as compensation for illegal copying of their works.

I was stunned when the levy was implemented in the face of well documented evidence that well under 10% of blank media is used in a manner which might reduce music industry revenues, but not at all surprised when courts ruled that payment of the levy entitles the purchaser to store copyrighted material on the media.

It's really quite bizarre - the music industry gets their cut every time you buy a blank in Canada, so if you don't use it to steal their products, you rip yourself off!

Triffid

Reply to
Triffid

Sure, the old ASIC boxes couldn't do AV and they needed a competetive entry to combat the SonicWalls and Fortigates, so they built the GT. Pretty simple.

It's definately an oddball and took them a while to sort it out. In fact, from projects I'm involved in that are deeply exploring feature sets of the GT, they still have problems to sort out, the sort of problems you just never saw in the ASIC based 5XT.

-Russ.

Reply to
Somebody.

Indeed, it's quite the challenge to present an identical look and feel, in both GUI and TTY, when the underlying architecture differs fundamentally - but IME they've done an excellent job.

Most of the NS boxes I 'own' are 500s, but I haven't encountered anything on the GT that seems unfamiliar or different - just some nicely implemented extra features that make it ideal for my purposes at home, like DDNS. I just assumed my GT was ASIC based like the rest. Thanks again for the enlightenment.

Triffid

Reply to
Triffid

The GUI and the CLI are identical indeed, it's the underlying guts that are so radically different. But even in new releases like 5.2 and 5.3, there are still significant bugs in the code. Your average home user probably won't find them, they're related to things like failover and traffic shaping for the most part, but in the business environment, these problems are just inexcusable in a product that's been around for about 2 years and comes from a company that normally has such solid products. And of course they expose just how inadequate NS tech support is, because no amount of reading a manual will get you past actual bugs in features you need.

-Russ.

Reply to
Somebody.

Some depends on your threat model. If you're just worrying about a computer/disk failure, adding TWO backup servers with large disks (old PC with BIOS mod or an O/S that doesn't care, to use large disk) is likely a cheap alternative. On the other hand, protecting against earthquake, fire, flood or theft means storing the backups off site.

Nice to know the indication of a bad disk - thanks!

Might be nice to talk to a lawyer about a 'Class Action' type of lawsuit if these are allowed under Canadian law.

How much was the levy? Is it worth buying over the border and paying the import duties?

I'm sure that was a screw-up in the wording of the original law. Gotta love it though. "Well Done, Canada"!

Old guy

Reply to
Moe Trin

Offsite storage is my primary reason for messing with tapes. The server is an old 440BX box with SCSI disks in RAID 5, and I have at least one spare for each of it's components.

According to The Register, the DRM cruft only (attempts to) support windoze, so you're safe.

They are. Worth considering.

It varies by media, currently $0.22 per blank CD - and in theory should be collected at the border, even on privately imported discs. Given I recently paid $23 for a spindle of 100 cheap blanks, one wonders if the importers are playing by the rules ;-)

I'm not. The levy amount is directly based on music industry calculations of their losses due to copying, divided by the volume of blank media sales - so the intent is clear. The government was careful to minimise their involvement - it's explicitly not a 'tax', in that the government charges the music industry for levy collection services, and hands the proceeds over to them for disbursement.

Triffid

Reply to
Triffid

For offsite storage, you could consider setting up a PC with GigE and a removable drive drawer and card (by Promise or similar) and then use IDE hard drives as your tape media. They're fast for partial restores (random access), and you save thousands on buying a tape drive, so on balance it works out cheaper. Plus, in a disaster, you need to get yourself another tape drive and identical software to do a recovery, do you have that handy? More thou$ands. Using IDE drives you can mount them anywhere and get at the data without complicated infrastructure. Lastly, if you end up needing "bigger tapes" you can just double up the hard drives and/or buy additional drives, the old drives can be deployed as storage for workstations, servers, mini-backups, whatever. Old tapes tend to go in the dumpster.

Just an idea.

-Russ.

Reply to
Somebody.

You'd also need a much larger storage area off-site. Disk drives come in those large foam supported containers for a reason. I'm also not that thrilled with the connector life on removable drives. It might surprise you to note that even MIL-Spec connectors have a surprisingly short life - as little as 500 mate/de-mate cycles.

Another technique is network storage. My sister lives 2200 miles (3500 KM) from me, and we have sections of each others file systems backed up over SSH. The link only carries _changes_ to the file systems (rsync is wonderful over a tunnel), so it's not a big deal. And yes, everything is encrypted before transit.

Good point - that's why I use the same equipment as the company uses (as well as other admins there).

Actually, our workstations tend to have small IDE drives because they are cheap. When we retire the workstations, they get a memory upgrade if they don't have the maximum, and the IDE stuff is replaced with big SCSI drives, and they become servers. The five exceptions are the ATAoE network storage systems we're experimenting with right now.

No, they go through the shredder first. Been doing it for years.

Old guy

Reply to
Moe Trin

Those are the reasons I put up with tapes when large IDE drives are cheap. My offsite storage is at my cottage, which is not accessible by road - so backup media is subjected to risky trips over water or ice depending on the season.

Now that is an appealing solution - one I intend to implement when (if?) an affordable broadband connection becomes available at the cottage. I'm comfortable with 250KM of separation.

I use the previous generation of company equipment - lower capacity and slower, but typically available free in quantities sufficient to guarantee availability in the event of disaster.

Triffid

Reply to
Triffid

In the San Francisco bay area, I swapped storage space with another admin who lived near the "other" fault (me = San Andreas, he = Hayward) but we were only about 20 minutes apart. Here, I've made similar arrangements. The tapes are in fire-resistant lock boxes.

See that the risks are sufficiently different (I assume you already have done this), and that power and communication aren't a problem (I don't have to worry about ice storms here, but we still have the occasional idiot who wants to drive through a power/telephone pole). The big advantage is that the backups are available in real time, if at slower bit speed. You also need to take extra care with the remote backup server (I use port knocking to open a hole in the remote firewall).

Absolutely.

Old guy

Reply to
Moe Trin

I could use one for a project that involves migrating a hundred or so firewalls from vendor x to vendor y. The code is mostly foo, and the quick'n'dirty approach of awking a static file with network bits in one column and dotted decimal masks in another works fine, but it offends my sensibilities slightly - however I'm not a shell script guru and google came up short.

TIA,

Triffid

Reply to
Triffid

Forward is possible:

awk '{x=$1;p=0;r="";do{if(p)r=r".";if(x>7){r=r 255;p++}else{s=0 for(i=0;i0);for(i=p;i

Reply to
Volker Birk

Only coincidental - there are only 32 such masks, and not all are used, so I've got them pretty well memorized. I have a dumb script

[compton ~]$ cat bin/masks grep -w $1 /home/ibuprofin/network/netmask.decimal if [ $? -ne 0 ] ;then grep -w $1 /home/ibuprofin/IP.ADDR/stats/non-standard.masks fi [compton ~]$

The reason it's grepping two different files is that the first is the "standard" set of values (data file is wrapped here for space):

255.255.255.252 /30 4 255.255.0.0 /16 65536 255.255.255.248 /29 8 255.254.0.0 /15 131072 255.255.255.240 /28 16 255.252.0.0 /14 262144 255.255.255.224 /27 32 255.248.0.0 /13 524288 255.255.255.192 /26 64 255.240.0.0 /12 1048576 255.255.255.128 /25 128 255.224.0.0 /11 2097152 255.255.255.0 /24 256 255.192.0.0 /10 4194304 255.255.254.0 /23 512 255.128.0.0 /9 8388608 255.255.252.0 /22 1024 255.0.0.0 /8 16777216 255.255.248.0 /21 2048 254.0.0.0 /7 33554432 255.255.240.0 /20 4096 252.0.0.0 /6 67108864 255.255.224.0 /19 8192 248.0.0.0 /5 134217728 255.255.192.0 /18 16384 240.0.0.0 /4 268435456 255.255.128.0 /17 32768 224.0.0.0 /3 536870912 [A /32 is all ones - a /0 is all zeros. /1 and /2 are highly unlikely, while a /31 is not useable because of lack of host space.]

The second file lists the 200 plus CIDR ranges used in RIR assignments. By this, I mean converting the decimal block assignments to something I can get my head around. As an example,

[compton ~]$ grep -cw 768 IP.ADDR/stats/[ALR]* IP.ADDR/stats/AFRINIC:3 IP.ADDR/stats/APNIC:0 IP.ADDR/stats/ARIN:417 IP.ADDR/stats/LACNIC:0 IP.ADDR/stats/RIPE:67 [compton ~]$ masks 768 768 3 x 256 196608 768 x 256 (3 x 65536) [compton ~]$

There are 487 RIR assignments of a block of 768 addresses - which is the equivalent of 3 former "Class C" networks. CIDR non-binary masks are not used as a _network_ mask, but are used for routing purposes. The 487 assignments of '768' hosts probably all use /24 masks and have three such subnets behind their gateway router, but it's nothing of our concern as we can't _do_ anything with that information. All we know is that 768 addresses belong to "that" entity.

grep is simpler ;-) The point is to use whatever works for you, and not worry about what others think. As mentioned above, I've got the regular values pretty much memorized as there's only about 10 I use regularly, and maybe another 10 on an infrequent basis. Not shown, but I've also got the hex equivalents because of a few BSD boxes.

Which shell? For about 6 years, I used the C shell, but have basically converted back to the Bourne - mainly bash - as it's more common. For bash, the Linux Documentation Project has a HOWTO

-rw-rw-r-- 1 gferg ldp 31540 Jul 27 2000 Bash-Prog-Intro-HOWTO

and two very good "guides"

drwxrwxr-x 2 gferg ldp 4096 Mar 2 2005 Bash-Beginners-Guide drwxrwxr-x 2 gferg ldp 4096 Oct 21 06:23 abs-guide

formatting link
for those two. The 'abs-guide' (Advanced Bash Scripting Guide) is quite a well written book. While it's written with Linux in mind, the concepts and examples are applicable to any O/S using a Bourne flavored shell.

Old guy

Reply to
Moe Trin

Jeez - you should be. ;-)

How so? While no RFC _requires_ that netmasks be contiguous ones, in practice, all modern O/S expect it to be so. If you are thinking CIDR block sizes, you must remember they are not network masks, but an indication of the size of an assignment. It _may_ take three or four mask values to describe, but it's one assignment. Ask RIPE about

194.9.124.0 which is an assignment of 720; 194.9.124.0 - 194.9.126.207, for example.

Old guy

Reply to
Moe Trin

Sure - pity the darn computer can't read my mind :-)

That's about what my file looks like - except I have 32-0 because they are all 'legal' so my code may as well handle them.

Pretty much my approach - I just prefer my firewall configuration munging script be self contained, and not have to carry around baggage in the form of a netmask conversion file.

Bash. I know enough shell script to get the job done, and rely on Unix in a Nutshell when I forget syntax - but it would take me longer than I can justify to come up with a one-liner like Volker's :-)

Triffid

Reply to
Triffid

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No. Just try it out. There should be no problem with Windows and Linux, for example.

The "many" was not meant as "many people use them", but as "there are

4 billion possible netmasks, but only 32 of them are displayable with /bits".

But anyway:

awk 'BEGIN{FS=".";print"obase=2"}{print$1;print$2;print$3;print$4}'| bc|sed 's/0//g'|echo $(wc -c)-4|bc

This counts bits in IP addresses.

OKOK, this all is as cute as the stuff on rotten.com ;-)

Yours, VB.

Reply to
Volker Birk

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.