[9fans] netpbm

[9fans] netpbm

[tapique]

those interested, grablatest version of netpbm at:

http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.26.1.tbz

please, test it heavily as it is intended to be included in the next official
release...
thanks,

++pac.


--------------------------
Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
Více na http://www.tiscali.cz

Re: [9fans] netpbm

[arisawa]

Hello,

How to unpack netpbm-10.26.1.tbz ?

term% gunzip netpbm-10.26.1.tbz
gunzip: netpbm-10.26.1.tbz is not a gzip deflate file
term%

Kenji Arisawa
E-mail: arisawa@ar.aichi-u.ac.jp

Re: [9fans] netpbm

[Lucio De Re]

> term% gunzip netpbm-10.26.1.tbz
> gunzip: netpbm-10.26.1.tbz is not a gzip deflate file

"bunzip2" rather than "gunzip".

Is it not possible to use a single utility that recognises the nature
of the archive?  Enhanced Unix "tar" utilities all seem to be able to
do it.

I haven't explored how it is implemented, but I recall vaguely a
discussion in one of the NetBSD mailing lists about trivially adding
bunzipping to TAR a long time ago.

++L


++L

Re: [9fans] netpbm

[geoff]

I've written a new (faster) tar and at Russ's suggestion have made it
recognise the compressed tar archives.  I think it's up to Russ
whether or not it becomes the sstandard tar.

Re: [9fans] netpbm

[Lucio De Re]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.  I think it's up to Russ
> whether or not it becomes the sstandard tar.

That has _my_ vote, for all it may be worth.  Maybe I ought to look at
integrating the various uncompressors or at least providing a single
front-end for them myself.  But these things just disappear into a
time warp as my time is too fragmented (bad habits) for me to conclude
anything of any magnitude :-(

++L

Re: [9fans] netpbm

[Lucio De Re]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.  I think it's up to Russ
> whether or not it becomes the sstandard tar.

I also note that APE has PAX in it, probably an ancient version.  I'm
no fan of PAX and I agree with Rob that APE is inconsistent with the
Plan 9 philosophy, but I don't think perpetuating obsolence is a great
option either, so updating ape/pax may be worth looking into.

++L

Re: [9fans] netpbm

[boyd, rounin]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.

i'm opposed. compress/uncompress programs should do that.

tar should tar.

or write a script that uses file etc and does the right thing.
--
MGRS 31U DQ 52572 12604

Re: [9fans] netpbm

[geoff]

Russ requested recognising compressed archives by name (e.g., *.tgz)
when extracting, and creating compressed archives under `rz'
key-letters, with the compressor determined by the archive name.  It
doesn't use a different key-letter (option) for each compression
scheme.  It's table-driven and just runs the appropriate compressor or
decompressor.  We've all got shell scripts to do this sort of thing,
but dealing with compressed archives is a common case and I don't see
much harm in having tar initiate one end of a pipeline internally
rather than requiring the user to do it externally.

My tar.c is 994 lines currently, a little bigger than
/sys/src/cmd/tar.c at 795 lines.  It looks like 102 lines are devoted
to dealing with compressed archives.

Re: [9fans] netpbm

[andrey mirtchovski]

> My tar.c is 994 lines currently, a little bigger than
> /sys/src/cmd/tar.c at 795 lines.  It looks like 102 lines are devoted
> to dealing with compressed archives.

how about the 128-character name limit which gnu tar has extensions for?

e.g. (original p9 tar):

plan9% touch `{perl -e 'print "A"x130'}
plan9% tar cv AA*
tar: name too long for tar header: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
plan9%

Re: [9fans] netpbm

[geoff]

My tar creates POSIX "ustar" archives by default, which can handle
names up to 255 bytes as long as they can be split at a `/' into two
strings, the first 155 or fewer bytes long and the second 100 or fewer
bytes long.  It also recognises "ustar" archives automatically when
reading archives, as does the standard tar.

Re: [9fans] netpbm

[geoff]

I should add that names are split only if necessary when writing
"ustar" archives, so "ustar" archives containing only names 100 or
fewer bytes long can be read with no problem by old tars.

Re: [9fans] netpbm

[Bruce Ellis]

Respect Doug.  Pipes are your friend. Or throw emacs into tar.
I'm sure that's not out of line with "don't use pipes".

brucee

On Fri, 4 Feb 2005 22:38:17 +0100, boyd, rounin <boyd@insultant.net> wrote:
> > I've written a new (faster) tar and at Russ's suggestion have made it
> > recognise the compressed tar archives.
>
> i'm opposed. compress/uncompress programs should do that.
>
> tar should tar.
>
> or write a script that uses file etc and does the right thing.

Re: [9fans] netpbm

[arisawa]

>Is it not possible to use a single utility that recognises the nature
>of the archive?  Enhanced Unix "tar" utilities all seem to be able to
>do it.
I have, but we should add more.

Kenji Arisawa

Re: [9fans] netpbm

[arisawa]

Mine is
#!/bin/rc -e
# unpack file ...
#   foo.gz   -> foo          in case of file.
#   foo.tar.gz   -> foo      in case of dir.
#   foo. -> DO NOTHING
#   foo  -> DO NOTHING
#
# coded by Kenar
#
fn usage {
	echo 'usage: unpack  file ...'
	exit usage
}

fn error {
	echo $*
	exit 'not found'
}

if(~ $#* 0) usage

while (! ~ $#* 0 ){
	x = $1
	if (test ! -e $x) error file $x not found
	f = 1
	while(~ $f 1){
	switch($x){
	case *.gz
		gunzip $x
		x=`{basename $x .gz}
	case *.tgz
		gunzip $x
		x=`{basename $x .tgz}^.tar
	case *.tar
		tar -xf $x
		echo rm $x
		x=`{basename $x .tar}
	case *.bz2
		bunzip2 $x
		x=`{basename $x .bz2}
	case *.tbz
		bunzip2 $x
		x=`{basename $x .tbz}^.tar
	case *.tbz2
		bunzip2 $x
		x=`{basename $x .tbz2}^.tar
	case *
		f=0
	}
	}
	shift
}

More decoding methods should be added.
And I rarely uses execept gzip.
Therefore not so much debugged.

Kenji Arisawa

Re: [9fans] netpbm

[Lucio De Re]

> More decoding methods should be added.
> And I rarely uses execept gzip.
> Therefore not so much debugged.

I'd think the plumber could be drawn into this?

	bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}

is my usual way to deal with this.

++L

Re: [9fans] netpbm

[arisawa]

> I'd think the plumber could be drawn into this?
>
> 	bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}
>
> is my usual way to deal with this.
>

good idea to plumb tar file. my preference is fs/tarfs.

Kenji Arisawa

Re: [9fans] netpbm

[Sam]

>> I'd think the plumber could be drawn into this?
>>
>> bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}
>>
>> is my usual way to deal with this.
>>
>
> good idea to plumb tar file. my preference is fs/tarfs.

In case no one has noticed, tarfs/tapefs is in man
sections 1 and 4, with the only difference being that
the section 1 variant documents zipfs.

Sam

Re: [9fans] netpbm

[andrey mirtchovski]

i liked this when i first saw it and still think it's relevant:

	http://cm.bell-labs.com/wiki/plan9/intro_to_tools_philosophy_for_*nix_users/index.html

whoever wrote it made a nice job explaining why it's pointless to hack
tar adding z (gzip/gunzip) and j (bzip2/bunzip2) options...

Re: [9fans] netpbm

[Lucio De Re]

> whoever wrote it made a nice job explaining why it's pointless to hack
> tar adding z (gzip/gunzip) and j (bzip2/bunzip2) options...

There's plenty of room for disagreement here:

	- The pipeline is not reserved for the shell's sole use.

		TAR can spawn a decompressor and read its output
		without user intervention.  The shell's contribution
		here would be the ease of change.  Casting it in TAR
		stone may (usefully ot otherwise) discourage
		enhancements (it didn't when Bzip2 was introduced).

	- Anything more complex than a pipe isn't suitable for purely command line use.

		TAR can inspect the archive and determine its format
		(it's a published header), selecting the most
		appropriate tool for decompression.  My suggestion was
		to move the identification into the decompressors, but
		in this case we're merely extending TAR's existing
		capabilities.  Whether the filename suffix is a
		suitable discriminator is for some other jury.  PAX,
		unless I'm mistaken, will even choose TAR or CPIO as
		the archiver, which is commendable if one is looking
		for simplification in a different realm.

	- One can push the principle to breaking point.

		"One task, one program".  By that token, there ought
		to be a TAR and an UNTAR as I don't see them as
		equivalent.  In fact fa/tarfs (or whatever) is a case
		in point and I have no reservations in this regard.
		But one can shift the "task" definition, too.  There
		are hundreds of archive formats, all in some use and
		having to be familiar with each is painful.  A utility
		that subsumes at least the extraction process into a
		single operation is not to be sneered at.  Of course,
		one has to be realistic, too.

In my opinion, the "one task, one program" principle is very sensible
for modelling and should only be abandoned when the components have
been so carefully tested that it is possible to combine them together
without major unpredictable problems being created.  Programming
skills have a great influence here: I would trust Geoff's
multi-purpose TAR more than I would trust my own simple attempt at a
TAR implementation.

++L

Re: [9fans] netpbm

[C H Forsyth]

>>Enhanced Unix "tar" utilities all seem to be able to do it.

i dare say it can.
cd /usr/src/contrib/tar; wc -l lib/*.c src/*.c
	... far too many files
   24449 total

and that's an old version. it has got `remote tape access',
though.  i'd forgotten about that. there's probably a command
language interpreter in there somewhere.

plan 9's pax is only 9000 lines, and is a little behind the times:
cd /usr/src/bin/pax; wc -l *.c
	...
    13455 total

does anyone still use cpio or pax?  apparently
it's like that OSI stuff that never quite dies,
however many stakes have been banged through its heart.

Re: [9fans] netpbm

[Tiit Lankots]

> however many stakes have been banged through its heart.

s/its heart/its black heart/

Re: [9fans] netpbm

[Derek Fawcus]

On Fri, Feb 04, 2005 at 09:31:30AM +0000, C H Forsyth wrote:
> does anyone still use cpio or pax?  apparently

Linux distributions...  At heart the archive inside a .rpm
file is in a cpio varient,  there is even a rpm2cpio filter.

Re: [9fans] netpbm

[Ronald G. Minnich]

On Fri, 4 Feb 2005, Derek Fawcus wrote:

> Linux distributions...  At heart the archive inside a .rpm
> file is in a cpio varient,  there is even a rpm2cpio filter.

linux initrd are now cpio archives.

ron

Re: [9fans] netpbm

[Charles Forsyth]

>> Linux distributions...  At heart the archive inside a .rpm
>> file is in a cpio varient,  there is even a rpm2cpio filter.

>linux initrd are now cpio archives.

i see.  clearly stakes didn't work on that one!

Re: [9fans] netpbm

[boyd, rounin]

> does anyone still use cpio or pax?  apparently

cpio should be dead by now -- horrible thing.
--
MGRS 31U DQ 52572 12604

Re: [9fans] netpbm

[Ronald G. Minnich]

On Fri, 4 Feb 2005, boyd, rounin wrote:

> cpio should be dead by now -- horrible thing.

it will live forever. No file format ever dies. Just look at SREC!

ron

Re: [9fans] netpbm

[boyd, rounin]

> it will live forever. No file format ever dies. Just look at SREC!

yuk, if you mean S-records.  gawd, i remember burning EPROMs with those.
--
MGRS 31U DQ 52572 12604

[9fans] factotum & invalid entries

[Tiit Lankots]

I don't have a secstore. Each time I connect to, say, sources, and I type
either an incorrect username or password, I can't connect (authentication
fails) until I clean factotum's database and get it correct the first time.

What exactly happens when authentication fails and factotum re-prompts
the user for credentials?

Re: [9fans] factotum & invalid entries

[Russ Cox]

> I don't have a secstore. Each time I connect to, say, sources, and I type
> either an incorrect username or password, I can't connect (authentication
> fails) until I clean factotum's database and get it correct the first time.

I think you are half-mistaken.  If you type a bad password, it should be
no big deal.  If you type a bad user name, that's when you get the
infinite loop.

> What exactly happens when authentication fails and factotum re-prompts
> the user for credentials?

If you type the same user name and a new password, then factotum
replaces the bad key, and all is well.  But if you type the wrong user name
the first time and then get it right the second time, factotum won't think
the two keys match (the user names are different!) so your key gets
added to the end of the list.  Factotum looks for keys to use from the
beginning of the list, so it finds the bad key again, and adding more
keys isn't going to help.

I changed things so that the new keys get inserted at the beginning
of the list.  That should help a bit.

Russ

Re: [9fans] netpbm

[arisawa]

Hello pac,

Thanks for your elaboration

term% tar -xf netpbm-10.26.1.tar
tar: mkdir /usr/pac failed: permission denied
tar: mkdir /usr/pac/wrk failed: '/usr/pac/wrk' does not exist
tar: mkdir /usr/pac/wrk/netpbm-10.26.1 failed: '/usr/pac/wrk/netpbm-10.26.1' does not
...

Therefore I used fs/tarfs + cpdir

Following your instruction in README.plan9

term% cp pm_config.9.h pm_config.h
term% cd lib
term% mk
libnetpbm.a doesn't exist: assuming it will be an archive
pcc -c -I .. -I util -B -D_PLAN9 -D_POSIX_SOURCE -D_SUSV2_SOURCE -I ../ -D_BSD_EXTENSION bitio.c
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] not a function
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] syntax error, last name: uint32n
pcc: cpp: 8c 2219: error
mk: pcc -c -I ...  : exit status=rc 2216: pcc 2218: cpp: 8c 2219: error
term% ape/psh
# pwd
/usr/local/src/pac/netpbm-10.26.1/lib
# mk
libnetpbm.a doesn't exist: assuming it will be an archive
pcc -c -I .. -I util -B -D_PLAN9 -D_POSIX_SOURCE -D_SUSV2_SOURCE -I ../ -D_BSD_EXTENSION bitio.c
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] not a function
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] syntax error, last name: uint32n
pcc: cpp: 8c 2364: error
mk: pcc -c -I ...  : exit status=rc 2361: pcc 2363: cpp: 8c 2364: error
#

It seems your help is needed.
Thanks in advance.

Kenji Arisawa

Re: [9fans] netpbm

[arisawa]

> Hello pac,
>

Sorry, that is thrown into 9fans. just my fault.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[YAMANASHI Takeshi]

> I changed things so that the new keys get inserted at the beginning
> of the list.  That should help a bit.

When the factotum is the one started by kernel on a cpu server,
adding a new key to the beginning of the list might change the
authdom which the cpu server running in?
--

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > I changed things so that the new keys get inserted at the beginning
> > of the list.  That should help a bit.
>
> When the factotum is the one started by kernel on a cpu server,
> adding a new key to the beginning of the list might change the
> authdom which the cpu server running in?
> --

That's a bad thing.  I put in a different solution.
Keys with a disabled attribute are passed over when
looking for keys to use during authentication.  If
factotum figures out that the key you've entered is
bad, then it adds "disabled=by.factotum" to the
key before asking for a new one.  All keys append
to the end again.

Let's see what breaks this time.

Russ

Re: [9fans] factotum & invalid entries

[Tiit Lankots]

> Let's see what breaks this time.

It seems to me like the semantically correct solution. Thanks!

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> Let's see what breaks this time.

Would anything break if factotum actually "delkey"ed the failed entry?

++L

Re: [9fans] factotum & invalid entries

[arisawa]

> Would anything break if factotum actually "delkey"ed the failed entry?
>

Russ will answer but I would like to say.
I think nothing break but I want the key is kept untouched only adding
disabled flag
at the beginning.
because the disabled key is useful to see what was wrong.
And I want, the disabled key is replaced by new one when I add new key.
Then I can edit factotum without changing the order.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> I think nothing break but I want the key is kept untouched only adding
> disabled flag
> at the beginning.

Hm. You can't inspect the password at that point (sometimes I wish
there was a way to do that) so just the username is pertinent.
Wouldn't a log entry be more useful and less intrusive?

++L

Re: [9fans] factotum & invalid entries

[arisawa]

> Hm. You can't inspect the password at that point (sometimes I wish
> there was a way to do that) so just the username is pertinent.
> Wouldn't a log entry be more useful and less intrusive?
>

I believe factotum does not keep clear password if proto=p9sk1
Then log entry will be useless even if the log shows the key.
If authentication failed and attribute value list is right except
password,
then we should retry with a new password.

Current factotum is inconvenient if the order is matter.
I think my proposal is one of idea to resolve the problem.
Of course if we failed in authentication, then disabled flag will be put
automatically at the beginning of the attribute value list, and if we
succeed
in next authentication the attribute value list is automatically
replaced by new
one without changing the order.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> I believe factotum does not keep clear password if proto=p9sk1
> Then log entry will be useless even if the log shows the key.
> If authentication failed and attribute value list is right except
> password,
> then we should retry with a new password.
>
That, unless I misunderstand Russ's comment, is already the case:
factotum will re-prompt if an attempted connection fails because of an
authentication error.  It is when a different username is submitted
that problems arise in the old style of operation where entries were
appended to the factotum database.

> Current factotum is inconvenient if the order is matter.

Correct: responding to a factotum request with a new username causes a
new entry to be created, whereas if only the password is different,
the previous entry is replaced.  The earlier entry, now with an
invalid username, will have priority over a subsequent correct entry,
invalidating the entire procedure (again, as things used to be).

> I think my proposal is one of idea to resolve the problem.
> Of course if we failed in authentication, then disabled flag will be put
> automatically at the beginning of the attribute value list, and if we
> succeed
> in next authentication the attribute value list is automatically
> replaced by new
> one without changing the order.
>
The point you raised was that you actually want to retain the error
entry for inspection which in my opinion causes more difficulty than
is justified.  A middle ground is to log the erroneous entry in the
same form as would be displayed by looking at the factotum database
and then discard it altogether.  This ought to satisfy your curiosity
and allow us to append new entries rather than prepend them, at the
same time removing the need for the "disabled" attribute.

Once we start treating sequence as significant (we already do, of
course), I think we tread on very thin ice.  Russ's idea of additional
attributes is a sound one to resolve possible ambiguities, rather than
rely on position in the database with all the associated risks.  For
example, what happens if I delete a key and resubmit it instead of
merely overwriting it (IPSO does that, doesn't it?)?  Are these
intentionally different in outcome?

In my opinion, factotum ought to detect ambiguous requests and have
rules for resolving them.

++L

Re: [9fans] factotum & invalid entries

[arisawa]

some miscommunication probably because of my sketchy explanation.

My image is
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
disabled key proto=p9sk1 dom=inside.plan9.bell-labs.com user=arisawa
!password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
term%

Factotum knows attribute value list is useless or not.
If the list is confirmed useless in authentication process,
I would like disabled is put at the beginning.
Next time I will fix the problem and put
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
then I will get
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
term%

If I put wrong user name, say alice instead of arisawa, then factotum
is not
authenticated. therefore we will get:
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=alice
!password?
term%
Wrong user name does no harm

The current problem is in that factotum put every data even if the data
is confirmed
invalid.

The above is rough sketch. we should examine more.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> The above is rough sketch. we should examine more.

If I read your explanation right, you misunderstand something.

	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?

would be valid if the password is correct.

	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=alice !password?

would be invalid if you're not registered as "alice" on sources.

Now, in my case, I always log onto my system as lucio, but as proxima
on sources:

	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=proxima !password?

Unlike pac, I do use the secstore.  But, before I put the "proxima"
entry in the secstore, I used to get prompted for authentication (the
dom= would cause this) and would regularly type "lucio" instead of
"proxima" as well as the wrong password to go with it.  I would then
get, instead of the above:

	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio !password?

and I'd religiously delkey the second entry before retrying for
exactly the reasons raised by pac and Russ.

Now, I submit that factotum would be right to "delkey" the second
entry as soon as it is aware that the authentication failed.  It
would, by default, overwrite the entry if I changed the password, but
it is not allowed to do so (by design) if I change the username.  I'd
like to stress that there are two conditions here: wrong password and
wrong username.  The first is not a problem, the second is, because
each new username adds an entry, but the first one has precedence.
Reversing the sequence of insertion solves the problem of precedence,
but leaves unwanted rubbish (the username is incorrect) in the
factotum database.  It has one additional side effect, incidental but
critical and Russ addressed that by "invalidating" the record.

In my opinion, that's the wrong approach.  I fail to see a negative
side to factotum deleting the erroneous record rather than flag it
"disabled".  I can see race conditions if different instances of
factotum are involved, possibly denial of service attacks, even, which
is why I asked whether anything would break.  I'm hoping that the
simpler approach is the way to go, anyway.  I am keen to create a log
entry, as, like you, I also like to know where I went wrong.  But
because factotum is required to hide information by design, I fear one
has to learn to minimise errors instead.

++L

Re: [9fans] factotum & invalid entries

[arisawa]

> 	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
> 	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio !password?
>
> and I'd religiously delkey the second entry before retrying for
> exactly the reasons raised by pac and Russ.
>
> Now, I submit that factotum would be right to "delkey" the second
> entry as soon as it is aware that the authentication failed.  It
> would, by default, overwrite the entry if I changed the password, but
> it is not allowed to do so (by design) if I change the username.

If factotum automatically changed
	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio
!password?
when it know the list is useless, you can add
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user= proxima
!password?
at the place of disabled entry. this is what you desire.
What is the problem?
If factotum have deleted erroneous record then factotum put next record
only at the end.  If order is matter this make a problem.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> If factotum automatically changed
> 	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
> 	disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio
> !password?
> when it know the list is useless, you can add
> 	key proto=p9sk1 dom=outside.plan9.bell-labs.com user= proxima
> !password?
> at the place of disabled entry. this is what you desire.

It's not what I desire: I don't want erroneous records in the factotum
database and I fail to see why anyone else would.  It solves a
non-existent problem, as deleting the record has the same effect.

> What is the problem?

Ugliness?  Note that the record is the most recently added record, so
the sequence is not affected.

> If factotum have deleted erroneous record then factotum put next record
> only at the end.  If order is matter this make a problem.

But factotum always did that, and it's precisely what I would do
manually.  As I mentioned, the sequence is not altered, nor should it
really matter if it was altered.

++L

Re: [9fans] factotum & invalid entries

[Russ Cox]

In response to the flood of messages in this thread:

- I decided against silently deleting keys.  It would be very
  confusing if keys just magically disappeared.  I like the
  disabled=by.factotum tag a lot better.  I didn't use the log
  file mainly because it's intended only for debugging messages.
  I wouldn't think to look there to figure out why a key disappeared.

- Adding disabled=by.factotum only changes whether
  factotum uses the key in authentications.  It doesn't
  change whether you can see the password.  You never can.
  That's the whole point of factotum.  Except in proto=pass,
  which exists to break the rule.

- Factotum has a precise semantics for disambiguating key
  selection: use the first one.  That said, there is nothing stopping
  you from adding your own tags and then using the -k flag to
  mount to resolve the ambiguity some other way.  This has
  been there since day 1.

- If you've developed a habit of deleting bad keys to avoid the
  original problem that was reported, you can drop the habit.

- When you add a new key with the ctl file, here is what happens.
  If there is already a key in factotum with exactly the same set
  of public attr=val pairs, that key is replaced with the new one
  and stays at the same place in the list.  Otherwise, the new key
  is appended to the list.  When doing this comparison, the role=
  and disabled= attributes are ignored.  This means that if you have
  a key like:

    key proto=p9sk1 dom=foo user=bar !password? disabled=by.factotum

  and you write a new

    key proto=p9sk1 dom=foo user=bar !password=quux

  to the ctl file, then the first key is replaced by the second.  But
if the first
  had an attribute baz=1 that the second did not, or vice versa, then
  the new key would just be added to the list.

There's a lot of incorrect speculation flying around about what
factotum might or might not be doing.  When in doubt, try it.

Russ

Re: [9fans] factotum & invalid entries

[rog]

> - When you add a new key with the ctl file, here is what happens.
>   If there is already a key in factotum with exactly the same set
>   of public attr=val pairs, that key is replaced with the new one
>   and stays at the same place in the list. Otherwise, the new key
>   is appended to the list.

does that mean it's now not possible to add a new key to the beginning
of the list (the old default)?

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > - When you add a new key with the ctl file, here is what happens.
> >   If there is already a key in factotum with exactly the same set
> >   of public attr=val pairs, that key is replaced with the new one
> >   and stays at the same place in the list. Otherwise, the new key
> >   is appended to the list.
>
> does that mean it's now not possible to add a new key to the beginning
> of the list (the old default)?

Yes, that functionality is gone.  No one ever seemed to need it,
and I don't know the right way to express it.  I left the machinery
that made it possible.  In general I think it's better not to use
ambiguous key patterns.

Russ

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> Yes, that functionality is gone.  No one ever seemed to need it,
> and I don't know the right way to express it.  I left the machinery
> that made it possible.  In general I think it's better not to use
> ambiguous key patterns.

echo 'key -a|b proto=...' > /mnt/factotum/ctl, analogously to "bind"?

For that matter, would ">" and ">>" possibly represent different
operations (ducks!)?

++L

Re: [9fans] factotum & invalid entries

[rog]

> For that matter, would ">" and ">>" possibly represent different
> operations (ducks!)?

according to the man page, they did before (or they would have if stat /mnt/factotum/ctl
yielded length>0) so you're not too out there...

Re: [9fans] factotum & invalid entries

[Devon H. O'Dell]

On Tue, 2005-02-08 at 18:55 +0200, Lucio De Re wrote:
> > Yes, that functionality is gone.  No one ever seemed to need it,
> > and I don't know the right way to express it.  I left the machinery
> > that made it possible.  In general I think it's better not to use
> > ambiguous key patterns.
>
> echo 'key -a|b proto=...' > /mnt/factotum/ctl, analogously to "bind"?
>
> For that matter, would ">" and ">>" possibly represent different
> operations (ducks!)?
>
> ++L

> means send output (stdout) to a file and overwrite its contents

>> means append output to a file

:)

--Devon

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> > means send output (stdout) to a file and overwrite its contents
>
Not necessarily, as rog pointed out, factotum retained the contents.
Other servers do likewise.

> >> means append output to a file

I never noticed a difference with factotum, although rog suggests
there was.  Maybe I should convince myself, I'll check when I get
home.  Options are ugly, but if there is reason to be explicit, then
I can't think of a better approach.

++L

Re: [9fans] factotum & invalid entries

[rog]

> I never noticed a difference with factotum, although rog suggests
> there was.

not quite.

the man page used to say:

: If the offset of the write is zero, the key is added at the beginning
: of factotum's list; otherwise, it is added to the end.

this would have meant that there was a difference between '>' and '>>'
*if* the length of the ctl file had been greater than zero (all '>>'
does is set the offset to the length returned from stat).  this would
have been an easy fix, if anyone had cared.

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > I changed things so that the new keys get inserted at the beginning
> > of the list.  That should help a bit.
>
> When the factotum is the one started by kernel on a cpu server,
> adding a new key to the beginning of the list might change the
> authdom which the cpu server running in?

I was working on factotum and I realized that this question
doesn't actually make sense.  The cpu server runs in as many
authentication domains as there are p9sk1 server keys in its
factotum.  It doesn't matter where you put the key -- beginning
or end of list.  In the p9any protocol, factotum will offer as possible
authentication domains all the proto=p9sk1 keys that
have no role attribute or an explicit role=server attribute.

It's not generally safe to be using the cpu server factotum as
your personal one, since adding new role-less p9sk1 keys
allows people in those domains to get in.  Probably the key
prompt should make sure to specify a role whenever it asks
for a key.

Russ

Re: [9fans] factotum & invalid entries

[YAMANASHI Takeshi]

> > When the factotum is the one started by kernel on a cpu server,
> > adding a new key to the beginning of the list might change the
> > authdom which the cpu server running in?
>
> I was working on factotum and I realized that this question
> doesn't actually make sense.  The cpu server runs in as many
> authentication domains as there are p9sk1 server keys in its
> factotum.

Oookay,  a cpu server can run in multiple auth doms!
I thought a cpu could only run in a single auth dom...

Is this the same for other services which authenticate via
factotum 'proto=p9any' that they accepts multiple auth domain as well?
I guess the answer is yes...
--

Re: [9fans] factotum & invalid entries

[Russ Cox]

> Oookay,  a cpu server can run in multiple auth doms!
> I thought a cpu could only run in a single auth dom...
>
> Is this the same for other services which authenticate via
> factotum 'proto=p9any' that they accepts multiple auth domain as well?
> I guess the answer is yes...

Anything that uses proto=p9any (factotum, cpu, etc.)
kind of runs in multiple auth domains, though the names
are treated as a flat space by the kernel.
Other services, like apop or p9cr, don't have p9any's
flexibility and are tied to a specific domain -- the domain
on the first p9sk1 server key.

Russ