On Sun, 21 Dec 2003, Orna Agmon wrote:
> On Sat, 20 Dec 2003, guy keren wrote:
>
> >
> > The slides are temporarily available at the following URL:
> >
> > http://users.actcom.co.il/~choo/users-processes-and-permissions/
> >
> > examples will be shown on a live linux system during the lecture.
>
> I think that the title of the whole lecture, occupying a great deal of the
> screen, should be ommited. It is enough that it is in the title of the
> page. The real heading of the page is hidden somewhere under tha nav bar.
me too. i was simply using alon's html breaking script.
i'll make them go away.
> I think when /etc/passwd is discussed, /etc/shadow should also be
> mentioned, as this is actually how systems work nowadays. You mention
> shadowwing, but not /etc/shadow
i intended to mention this file, and then forgot it.
ok, added two slides for this file.
> slide 6: I find the last line redundunt. saying "normally" is enough to
> say that sometimes it is not, and if you you say nothing of it now, there
> is not point to add another line saying you are not saying anything.
it is there to emphasize that there are exceptions. if i didn't write it,
people will forget about the exception. besides, this line has a literary
value, as it advances the plot...
> You use the terms owner, group, others. this is very confusing (I was
> confused like this for years):
>
> chmod o+w is not for the owner: o stands for others. whereas a stands for
> all. Using "owner" all along the lecture would imprint the term owner.
which is why i keep using the term 'User owner', rather then 'owner'.
i added hyphens now (i.e. User owner -> User-owner), and changed any
instances of 'owner' to 'User-owner' and of 'group' to 'Group-owner'.
but be sure that people WILL see the original terms used often....
> I think also a very important thing to teach is to check after yourself when
> you change permissions, at least in the first few times, to see you did
> what you intended. And only that.
this is something i will mention during the lecture. how would you put it
in the slides, and where?
> slide 10:I would reccoment doing the RWX letters upper caps, like you did
> with the U,G upto that point.
i use lower-case letters, since these are actual letters people need to
type in commands. if i will use upper-case letters here, people might be
confused to trying to use the upper-case letters in the command, and then
wondering why it did not work.
> Many slides are bigger than a screen (at least mine). Uncomfortable for a
> lecture.
i know, but i didn't want to break them down, to avoid losing focus. i did
break down those that looked appropriate for breaking.
> slide 12: s/Lets/Let's/ (Let's is a short for Let us)
ok.
> 13: the font of the example is way too small. Check out the size of the
> font is the basic admin lecture- people complained on its small size then.
i enlarged the fonts for the various examples in the slides.
> 14,15: Capital letters on the "give" lines.
ok.
> 15:Ask the system administrator to create a new group containing this
> list of users: I think we should assume they have (at lesat some of them )
> access toroot, and teach how to do that.
they'll do that via the GUI. since i don't have a redhat 9 system, i can't
write how this is done. i might demonstrate doing this by manually editing
the "/etc/group" file. you think it's wise to show that? ;)
> 16:Make the Group-owner of the file be this group: I think the slides
> should mention chgrp.
i showed 'chgrp' in the previous slide. there was no point in repeating
the entire commands list here too.
> 21: I think we should teach also (and in my opinion, instead) the shell
> commands which do similar actions: ^c, bf, fg.
i thought about it, but then decided that job-control is too much for this
lecture (it is a _very_ confusing issue, with processes seeming to have
vanished, while they are actually still alive and kicking, etc). i leave
the whole issue of job-control via the shell, to a lecture about usage of
the shell.
> It is dangerous to send
> commands with kill, because a kill might be sent by mistake. and we should
> warn that replacing the order of the pid and the signal is hazardous-
> it creates kill -KILL instead of what we wanted.
i'll mention it during the lecture. and it won't help - people will have
to kill their own shell once or twice, in order to learn to be catious...
> 22: in "Other then the": s/then/than/
ok
> 23,24(twice): in "rather then": s/then/than/
actually, 3 times on all slides together. fixed.
> 26: when my screen is too narrow, the lines (with pre) go out of the
> screen on the right, but the frame does not. Not that I think that there
> is anything to do abou this, but maybe somebody else knows.
i saw that, and don't know why this happens. this is alon's style - he
should know.
> This is the first time you show how the permissions are written (in tris
> of wrx). And you never explained so far the fact that it is abinary
> representation, and you can access the chmod in octal, and from what side
> to what do you read the number (little/big endian).
this is because i don't want to confuse people. they can use the 'a+x'
notation for everything - the octal representation is redundant, and is
too much for this lecture. and i don't care if you think it's better,
faster, stronger or more optimized - it is beyond the scope of the
lecture.
> you say that the
> permissions of 888 are not necessary for a symlink. I never changed those,
> but I assume this works as a bitwise and with the permissions of the real
> file. anyway, please say something about this.
i won't. it's out of the scope.
> also: when you chmod a
> symlink, you chmod only the link, not the file, right?
here is what the man page of 'chmod' has to say about this:
-----------------------------------
chmod never changes the permissions of symbolic links; the
chmod system call cannot change their permissions. This
is not a problem since the permissions of symbolic links
are never used. However, for each symbolic link listed on
the command line, chmod changes the permissions of the
pointed-to file. In contrast, chmod ignores symbolic
links encountered during recursive directory traversals.
-----------------------------------
thus, chmod effects the final file, not the symbolic link(s). anyway, i'm
not sure i am going to mentoin this during the lecture, unless someone
asks.
> you can remove only
> the symlink, but if you do rm -rf to the symlink, and it is a directory,
> you will remove real files. so they should be warned about this- this is
> not hazard-free.
nothing is hazard-free. however, they are not supposed to know about 'rm
-rf' - we never taught them that, did we? ;)
> 28:"to see the a" should have a capital T.
ok
> 29: I personally find the summary line :"Google for them all on your spare
> time.."
> improper.
improper in what manner? i am trying to say "you'll need to learn about
these issues on your own, because we are not showing them here". they are
bound to stumble on these issues sooner or later - so i just make them
known by name.
> you need a summary slide, which will say what you DID cover.
i'll leave that to the verbal summary - the slides conain the summary as
the 'table of contents'. if this was a long book, this would be a good
idea. for one lecture - i'm not sure it's a good idea to put it in the
slides themselves.
> and I think
> you should talk about sticky bit aswell, to make the picture full.
ah, the sticky bit. remind me what it does? ah, it is what makes the
'/tmp' directory so confusing. i'd rather not get into that during this
lecture...
ok. updated slides are found in the same loaction (comprssed format too,
at http://www.actcom.co.il/~choo/users-processes-and-permissions.tar.gz)
--
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
--------------------------------------------------------------------------
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]
