December 2003 - cypherpunks-legacy

Checklist
by Daniel Colpi 17 Dec '03

17 Dec '03

Greetings and Salutations, A few days ago, I asked for help in making a step by step list on how to "copy" OpenBSD from one computer to another. Well I got a few answers, but many people wanted me to post this list when I was done. So this is it, a mindless checklist of everything I did to "convert a DEC 3100 to the Dark Side" If you can think of something I have missed, please throw me an e-mail. Thanks Daniel Colpi colpi(a)purdue.edu ====================================================================== So, you want another OpenBSD computer hu? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (assuming same disk setup, target is disk #0, and source is disk #1) (also assuming rrz0a -> / ; rrz0c -> swap rrz0d -> /usr ; rrz0e ->/usr/target ) (Note: I am on a /bio backbone, this isn't going to be the same for you) (Note: /bio/scratch3 is a temp space that I can write to) ___Save Files ___dump root to scratch (just in case) -->% dump -0f /bio/scratch3/dump /dev/rrz0a ___/etc/passwd --> % mv /etc/passwd /bio/scratch3/passwd.target ___/etc/crontab ___any self created scripts you made to run with crontab ___/etc/fstab ___/usr/local/etc/mk-exports ___/etc/export.hosts ___/etc/export.fs.[n] (if you have a drive that is set up the way you want for target machine, you might want to save it to a file to save you some time) (Note: you might want to do this on a machine that is already converted) ___save your partition list -->% disklabel -r /dev/rrz1a >> temp_part % mv temp_part /bio/scratch3 ___Shut down target ___Connect source drive ___Make sure drives are jumpered not to conflict (target=>0 ; source=>1) ___Plug in and power up ___Make sure clock is right time (some old computers lose some time) ___Make sure you see both drives (ie drive 1 & drive 0) ___Run disklabel (I had drouble labeling the disk, but this worked) -->% disklabel -r /dev/rrz1a >> temp % disklabel -B -R /dev/rrz0a temp % disklabel -e /dev/rrz0a ___ / = _______________ ___ swap = ____________ ___ /usr = ____________ / ______________ (target / source) (remove src if desired) ___ /usr/target = _______________ (if you have a "cookie-cut" version you can just:) -->% disklabel -B -R /dev/rrz0a /bio/scratch3/temp_part ___Run newfs -->% newfs /dev/rrz0[ad] ___Transfer files --->% mount /dev/rz0a /mnt % cd /mnt % df -k . (make sure enough room) % df -k / % dump 0f - /dev/rrz1a | restore -rf - % rm restoresystable (if you don't do this you'll be sorry) % cd / % umount /mnt % mount /dev/rz0d /mnt ---+ % cd /mnt | % df -k . | Repeate this % dump 0f - /dev/rrz1d | restore -if - | section if restore > add [all dir's you want to keep] | needed restore > extract | on restore > set owner/mode for /./? [yn] n | other restore > quit | partitions (Note: it will say "DUMP not completed" if you | did not restore everything. This is not a bad | thing, ignore it) | % rm restoresystable (might not be there) | % cd / | % umount /mnt ---+ ___Configure (BE CAREFUL to configure /mnt/etc NOT /etc !!!!) ___mount /usr --->% mount /dev/rz0d /mnt ___remove /mnt/etc/npt.drift ___make dir /mnt/usr/preserve ___replace all scripts made to be run by crontab ___move /bio/scratch3/mk-exports /mnt/usr/local/etc/mk-exports ___umount /mnt ___mount / --->% mount /dev/rz0a /mnt ___replace rest of scripts to be used by crontab ___move /bio/scratch3/export.hosts /mnt/etc/export.hosts ___move /bio/scratch3/export.fs.[n] /mnt/etc/export.fs.[n] ___hostname ___/mnt/etc/hostname.le1 ___/mnt/etc/exports (or run /usr/local/etc/mk-exports) ___/mnt/etc/hosts (change IP number too) ___/mnt/etc/myname ___/mnt/etc/rc (maybe not if (flavor == vanilla)) ___/mnt/etc/mygate ___/mnt/etc/passwd ___/usr/local/bin/tcsh (OpenBSD doesn't come with tcsh) ___reconfigure passwd file (for correct format) __ % mv /bio/scratch3/passwd.target /mnt/etc/passwd.orig same / % nawk -F: ' { print $1 FS $2 FS $3 FS $4 "::0:0:" $5 FS \ line \__ $6 FS $7 } ' /mnt/etc/passwd.orig >> /mnt/etc/passwd % pwd_mkdb -c /mnt/etc/passwd % pwd_mkdb -d /mnt/etc/ /mnt/etc/passwd % pwd_mkdb -d /mnt/etc/ -p /mnt/etc/passwd % chmod 600 /mnt/passwd.orig ___do you want permissive /mnt/root/.rhosts (bilbo root ; gimli root) ___how about cooperative /mnt/etc/ttys (%s/network/network secure) ___if your source machine boots off disk 1 and target boots off disk 0, you need to make sure the correct kernal is at /mnt/bsd ___umount /mnt ___Power down ___Remove source drive ___Correct jumpers if nessary ___Power up ___Before starting OpenBSD at Boot Ram type: >> printenv >> setenv bootpath rz(0,0,0)/bsd ___Boot off of target disk ___restore user file system --->% cd /usr/target % rsh bilbo ls /usr/amanda/\* __ (now in order) same / % rsh bilbo cat /usr/amanda/target.date.[0->(n-1)] \ line \__ < /dev/null | resore -rf - (now when done with above loop (IN ORDER!!!!!)) % rm restoresystable ___recreate crontab --->% crontab -e ___Checks ___ping source machine (to make sure not same IP addresses) ___run ntpq -p ___finger @localhost ___finger @target ___cd into /bio/scratch3/ ___run date ___telnet to target from another machine ___ftp one file from another machine ___cd to /bio/target from another machine ___Go home early Nessary Tools: =============== Screwdrivers (if internal drives) Postit-notes (for keeping drives straight) One hell of a lot of coffee

1 0

Re: Documentation
by Charlie Root 17 Dec '03

17 Dec '03

> >In the coming weekend, I'll be updating the newuser FAQ > >(for things like PPP and 2.2). I'm sure a post-install checklist would be > >a welcome addition. > > > >B U T . . . . > > > >Not everyone runs things like Kerberos or DNS. Keep in mind that many > >people use OpenBSD for many things and in many environs. The OpenBSD setup > >on my firewall at the office is much different than the Sparc, Alpha, and > >P5/133 I run it on at home. The setup on my router machine at home is also > >much different than the other machines in my house. There are ways people > >have setup OpenBSD on embeded systems to do things like manage the > >fuel/air mix ratio on their Corvettes (OK, one person I know of planned > >that, but couldn't get the financing for the car...) I hope that draws the > >picture. > > > >As for the verification after install, that is sort of "auto-manditory"-- > >if a filesystem isn't mounted right, /etc/fstab has to be checked out. If > >the network doesn't work, the network files must be examined to "make it > >go." As oopposed to attacking this as a checklist, how about it is > >attacked as "If networking doesn't work, check hostname.(interface)"-- but > >there is more to that then just files in /etc (boot -c in order to > >reconfigure hardware addresses) > > As a user of OpenBSD, and having tried to manage projects with it for > implementation of added features for customers...I could not agree with > the above position. > > You see, if you are ALREADY familiar with OpenBSD then you will most likely > know exactly what to do when installing and seting up a system. New User's > Notes / Installation Checklist's will most likely be ignored by you. > > However, if you are brand new to the system, then an Installation / Setup > Checklist (a good one) will prove to be essential. Wouldn't it be great if > just about every post to these groups from a new user was one like "..hey! > This OpenBSD thingy works great! The installation was a snap!.." or something > like that. We all know that hardly happens now...but, it could..... > > I, for one, believe strongly that a good 'Overview', 'Setup Notes' and 'Installation > Checklist' must somehow find it's way into the distribution. It is also clear > that the machine / arch specific differences will require unique versions > for each. I completly agree with you. Just anoze topic that i can add is installation procedure,especially disk partitoning. It's a very dungerous/important procedure but it's description ins INSTALL.i386 is a bit too short and need examples(espcially). Something like - "Imagine we have disk with such and such patitions and now we want to install OpenBSD here & there so we should... It would'be _very_ helpfull. BTW, does anybody work on installation software ? Something like in FreeBSD/RedHat ? Alexey Pialkin

1 0

Collisions
by Daniel Colpi 17 Dec '03

17 Dec '03

Greetings and Salutations, Does anyone know of where I can get some sort of window to "catch" all of the system mess. while xdm is running? There are a lot of collisions that happen, and they mess up the screen with error mess. The people who use these computers assume the this is broke. Any ideas? Thanks, Daniel Colpi colpi(a)purdue.edu

3 3

pro-crypto govt. people
by Stanton McCandlish 17 Dec '03

17 Dec '03

This year I recall seeing 1 former prosecutor saying that widespread encryption was good and/or that GAK was bad, and 1 military or former military person of fairly high status saying that GAK was bad. Circa 1994-5 I also recall a military or retired miltiary person of rank reporting that very widespread crypto would be a boost to national security. We could really use these people's, and similar people's, words in pro-crypto efforts. Unfortunately, disk problems a while back cost me most of my old mail, including all of these saved items. If anyone has them and/or knows who these people are, please let me know. -- Stanton McCandlish mech(a)eff.org Electronic Frontier Foundation Program Director http://www.eff.org/~mech +1 415 436 9333 x105 (v), +1 415 436 9333 (f) Are YOU an EFF member? http://www.eff.org/join

6 5

Bernstein case update: Government appeal brief filed
by John Gilmore 17 Dec '03

17 Dec '03

The government has filed its 81-page "brief" with the Ninth Circuit Court of Appeals in the Bernstein case. They argue that the export controls are "constitutionally permissible", that they are not a facially unconstitutional prior restraint on publication, and that the District Court gave Prof. Bernstein "too broad" relief by declaring the law and regulations unconstitutional and partially enjoining their enforcement. The brief has been scanned in as page images, and is at: http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/Legal/970116_appeal_brie… Prof. Bernstein's legal team will file its reply by November 10, the government will reply by November 17, the Court will hold a formal hearing sometime during the week of December 8, then the Court will issue its decision. John Gilmore Electronic Frontier Foundation

1 0

Free Internet Seminar
by Jeremy Rusnock 17 Dec '03

17 Dec '03

Dear MIS Subscriber, MicroServe will be holding a basic Internet seminar on Tuesday, October 21st at teh Woodlands Inn and Resort in Wilkes-Barre, PA. There will be two sessions from which to choose, 1:00pm to 4:00pm or 6:00pm to 9:00pm. We will be covering basic services such as email, ftp, world wide web, and usenet news. We will also provide information about the internet itself - how it started, where it's going, etc. Everyone is welcome (whether an MIS customer or not), so tell your friends and family. Again, this is a basic seminar. We will not be covering advanced topics such as web page creation or cgi programming. So if you are an advanced user already, this might not be the seminar for you. We are considering advanced seminars in the not too distant future. If you would like to register or if you have any questions, please call Mike Siconolfi at 821-5964 x21. Thank You, Jeremy Rusnock ~----------------------------------------------------------------------- Jeremy Rusnock MicroServe Information Systems, Inc. Commercial Sales/CSM/Security 100 North Wilkes-Barre Boulevard jeremy(a)admin.microserve.net Wilkes-Barre, Pennsylvania 18702 http://www.microserve.net/~jeremy (800)380-INET x23 (717)821-5964 x23 ------------------------------------------------------------------------ Free on Saturday? Play Ultimate. See http://www.microserve.net/~frisbee.

1 0

Re: what can we do about PGP sell out and CMR?
by Anonymous 17 Dec '03

17 Dec '03

You've got a lot of nerve accusing PGP, Inc. of being "sellouts" when you're over on open-pgp pushing KEY ESCROW, of all things. I can see it now, the new product name, "PGP with Key Escrow". Motto: "Lose your key? Don't worry, we've got a copy." Do you really think cypherpunks are going to support key escrow? Fat chance.

2 1

finger
by Harry Hansen 17 Dec '03

17 Dec '03

______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: Security flaws introduced by "other readers" in CMR
by Anonymous 17 Dec '03

17 Dec '03

Let's look a little closer at the kinds of access and notice available in the PGP system compared to alternatives. As several people have pointed out, no encryption system can provide protection against what is done with the message after it is decrypted. The receiver could share it with whoever he wants to, or whoever he is forced to. Consider the following scenarios: - An encrypted message is sent to someone at his workplace using current systems like PGP 2.6. - An encrypted message is sent to someone at his workplace, who is using the message access features of PGP 5.5. The corporation key is marked as "optional", and the message is not encrypted to that extra key. - An encrypted message is sent as before, but this time the message is encrypted to the corporate key. - An encrypted message is sent to someone at his workplace, who is using a different form of corporate access which relies on key escrow or automatic acquisition of cleartext. We agree that none of these systems can provide complete protection against third party access. In any of them, the receiver could be forced to turn over the encrypted message. But there is still a difference. In the first two scenarios, the expectation of privacy is the same. You are encrypting to a personal key at a business address, but you expect that you would know about it if the data were being provided to a third party. There is no widespread installed base of software which provides secret access after the message is decrypted. In fact, the second scenario arguably provides slightly more privacy than the first, which is what we have now. The reason is that in the second scenario, the company provides an optional mechanism for business mail to be recoverable, but also provides an explicit, sender-controlled escape clause. The company is granting an explicit expectation of privacy by allowing the corporate key recipient to be removed. With usage of older versions of PGP, there was really no way for the company to even inform the sender about whether it was going to be reading the mail. In the third scenario, where you encrypt to the corporate key, there is no expectation of privacy. All parties, the sender, the receiver, and the company, know that the data is being made available to the business. There is not much privacy here; what you have is business security. This mode would be used for business documents and business communications. In the fourth scenario, which some people are offering as a superior approach, the expectation of privacy is much less clear. Unlike in the current PGP approach, where the design of the corporate access system is oriented around notifying the sender and receiver, a key escrow or plaintext recovery system inherently provides no such notice. This is different from the status quo. We are talking about a commercial product which provides automatic corporate access to communications. Widespread installation and use of this alternate version of PGP inherently changes the assumptions and expectations that you will have when you encrypt to someone at work. Given the company's desire for message access, this approach implies that you must conservatively assume that most encryption to a business address will be read. The PGP system is designed to avoid this. It provides another method for corporate access, a visible and explicit method. It is intended as an alternative to key escrow and other systems which recovery data after the recipient gets it. PGP's third party recipient feature is designed to prevent the creation of an installed base of escrowed keys and after the fact third party access software. Even if the encryption system provides a way for the user to mark his keys as being escrowed or otherwise providing third party access, the system is not self-correcting in the way the PGP system is. It would be much easier for a business owner to pervert a secretive access system than one like PGP. The company could install the access features but not tell its employees that their keys were being escrowed, or that their mail client was secretly storing a copy of all plaintexts. This kind of change would be easy to make with the after-the-fact access systems some people are proposing. Yes, theoretically this can be done with any encryption system (as all agree) but the point is to avoid the widespread distribution of software which invites this kind of abuse. The PGP system is designed to satisfy business needs without leading us into this dangerous situation. A world in which third party encryption by the sender is the normal and widespread method for corporate access is one with increased privacy and more visibility of access. The alternatives which have been proposed are prone to abuse and provide less visibility. They lead us towards a world in which there is no expectation of privacy even for encrypted messages, by providing an installed base of snooping software. The PGP approach is explicitly designed to keep us out of that world, by removing the need for that kind of software.

3 2

InfoWar Epilogue 3 (Part III of 'The True Story of the InterNet')
by I Am Not A Crook Remailer 17 Dec '03

17 Dec '03

1 0