Re: [Haifux] Some notes regarding the instaparty
On Thu, Mar 06, 2003 at 08:34:44PM +0200, Adir Abraham wrote: As long as Erez didn't say anything else - we know that we will install everything, and no CDs will be given, unless Actcom or any other organized company/faclty will be there and sell. This is what I'm waiting for, and Orr or Yuval should update me with. Do you (or any one else) have any problems with Hamakor (as represented by me and/or other board members) selling CDs and registering members during the instaparty? if yes, why? Thanks, Muli. -- Muli Ben-Yehuda http://www.mulix.org pgp0.pgp Description: PGP signature
[Haifux] Re: I had enough [was: Linux party!]
On Thu, Mar 06, 2003 at 08:57:24PM +0200, Orr Dunkelman wrote: Of course nobody has problem with ha'makor. Actually we will be very happy to have them coming in, with CDs, registration forms, and the wet penguin contest. Great! See y'all at the party. Please inform neighbours, friends, rivals, journalists, journaled file systems, etc. about the insta party. Don't forget linux-il and the various linux forums. -- Muli Ben-Yehuda http://www.mulix.org pgp0.pgp Description: PGP signature
Re: [Haifux] Huge file with static linking
On Thu, Mar 06, 2003 at 09:22:46PM +0200, Eli Billauer wrote: And here's my little session: [EMAIL PROTECTED] helloworld]$ gcc -static -o hello hello.c You forgot -O2, and you forgot to give your machine a name! [EMAIL PROTECTED] helloworld]$ ls -l hello -rwxrwxr-x1 eli eli441940 Mar 6 21:05 hello* [EMAIL PROTECTED] helloworld]$ You forgot to run strip(1). Any suggestions of how to shrink this down to some normal size? strip(1). Anything beyond that requires assembly and careful massaging. Thanks in advance, We aim to please. -- Muli Ben-Yehuda http://www.mulix.org pgp0.pgp Description: PGP signature
Re: [Haifux] Huge file with static linking
On Thu, Mar 06, 2003 at 09:45:36PM +0200, Eli Billauer wrote: strip(1). Anything beyond that requires assembly and careful massaging. Really? This is the end of it? How come /sbin/insmod.static is so small? What do they know that I don't? Do you know for a fact that insmod.statis was compiled with -static? I was under the impression that strip does a good job even when using -static. Apparently, it doesn't. I'll think about it, and if anyone knows how to get the binary's size down after strip is done with it, do tell. -- Muli Ben-Yehuda http://www.mulix.org pgp0.pgp Description: PGP signature
Re: [Haifux] My Modem, the Kernel and Me
On Sun, Feb 23, 2003 at 12:50:59AM +0200, guy keren wrote: On Wed, 19 Feb 2003, Muli Ben-Yehuda wrote: On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: original configuration, and noone was really sure. I don't think that there is someone here who can tell me exactly what files are tampered with during all the makes (could syscalltrack be handy here? ;). All this makes kernel compilation a mysterious adventure, with no promised way back home. If there was as little as a list of directories to back up before starting, it would all look different. Eli, It's not voodoo. It's not a mystery. It's code, plain and simple, there for the reading. Please read the Makefile and write a comprehensive list of files which are changed. I'm sure kernelnewbies.org will be happy to put it on line. actually, there's a contradiction there. if it was that simple, there would be no need to write a doc for it and place on kernelnewbies. I didn't say it's simple, I said it's code, plain and simple. as in you have the documentation, it's the code. Makefiles are usually hard-code to read, and writing Makefiles which are easy to maintain as well as easy to read, is a difficult task. specifically, the Makefiles of the linux kernel are not easy to figure. the fact that you deal with them for quite some time now, and you read them rather easily, is not an evidence to how easy it is to read them for the first time. this is especially tru when you have a specific goal in mind (such as - how do i get this module to work). I agree here. Don't take me wrong: I think that the possibility to compile the kernel is one of the beauties of Linux, and writing in kernel space is something I know I'll do sooner or later. The problem is that it's such an unfriendly field, and for no real reason. Did you read the books? did you read the source? where else did you expect the knowledge to come from? from good documentation, ofcourse. the linux kernel comes with lots of documentation, but without something large to show the architecture of the beast, and how it all fits together. specifically, i'm not aware of good documents that deal with the Makefiles - is there? for the kernel itself there is 'the linux kernel' in the Linux Documentation Project - thoughts its not deep enough for my taste. Linux Device Drivers, 2nd Edition (available online). Understanding the Linux Kernel, 2nd Edition (highly recommended). The linux-kernel mailing list archives. The lwn.net kernel summaries (very highly recommended), and kernel traffic. http://www.kerneltrap.com, http://www.kernelnewbies.org. As for the Makefiles specifically, in 2.5, 'make help' should be a pleasant surprise, the Makefile begins with a documentation section and there is Documentation/kbuild/*. 2.4 is not quite as well endowed, but neither is it completely lacking. c. Run 'make oldconfig; make dep'. This step prepares the intermediary kernel configuration and build files that are needed for the build process. Amongst other things, it handles module version. Thanks. make oldconfig was the secret. And a secret it is. Just for the fun of it, does anyone know exactly what it does? What old configuration are we talking about? And make dep afterward fixed it all. It takes .config, all of the configuration symbols in this kernel, and only asks you about new or changed configuration options. It's used when you already built a kernel, and then a new version is released. You copy the same .config over and run 'make oldconfig', and instead of dealing with hundreds of configuration options, you only deal with the delta. As a side effect, it also creates some files that tell the build system that it has been configured, and (I think) creates the include/asm-$(ARCH) - include/asm symlink. just as a note - i have been compiling linux kernels for several years, before i heard about 'make oldconfig' for the first time - and i did read some of the documentation that comes with the kernel during that time. in fact, i got so used to reconfiguring it manually, that i keep forgetting about 'make oldconfig', and thus configuring a new kernel keeps taking me 30-60 minutes every time ;) You should start doing it 15 or 20 times at a stretch, that will cure your memory in a hurry ;-) Here's my currently running kernel: [EMAIL PROTECTED]:~$ uname -a Linux tea 2.5.62-mx #34 SMP Sat Feb 22 09:28:42 IST 2003 i686 unknown the #34 there means that it's the 34th compilation of this kernel tree... Start with the top level Makefile and Rules.make, and follow what happens when you run 'make oldconfig; make dep'. Yeah, right. I wanted to install a linmodem driver, not explore the mysteries of makefile, sed and bash, and virtually every possible system file. You want knowledge. I told you where it is found
Re: [Haifux] My Modem, the Kernel and Me
On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: original configuration, and noone was really sure. I don't think that there is someone here who can tell me exactly what files are tampered with during all the makes (could syscalltrack be handy here? ;). All this makes kernel compilation a mysterious adventure, with no promised way back home. If there was as little as a list of directories to back up before starting, it would all look different. Eli, It's not voodoo. It's not a mystery. It's code, plain and simple, there for the reading. Please read the Makefile and write a comprehensive list of files which are changed. I'm sure kernelnewbies.org will be happy to put it on line. Don't take me wrong: I think that the possibility to compile the kernel is one of the beauties of Linux, and writing in kernel space is something I know I'll do sooner or later. The problem is that it's such an unfriendly field, and for no real reason. Did you read the books? did you read the source? where else did you expect the knowledge to come from? c. Run 'make oldconfig; make dep'. This step prepares the intermediary kernel configuration and build files that are needed for the build process. Amongst other things, it handles module version. Thanks. make oldconfig was the secret. And a secret it is. Just for the fun of it, does anyone know exactly what it does? What old configuration are we talking about? And make dep afterward fixed it all. It takes .config, all of the configuration symbols in this kernel, and only asks you about new or changed configuration options. It's used when you already built a kernel, and then a new version is released. You copy the same .config over and run 'make oldconfig', and instead of dealing with hundreds of configuration options, you only deal with the delta. As a side effect, it also creates some files that tell the build system that it has been configured, and (I think) creates the include/asm-$(ARCH) - include/asm symlink. And you were right about the /boot directory. There are config-files for each binary to boot, so it seems like the way to just recompile a certain prebuilt binary is to copy one of these into /usr/src/linux-x.x.xx/.config . This might be the answer to my original question: How do I turn things back to where they were? But I haven't really tried this, though. I might soon. You save your .config and run 'make mrproper', which is like 'make distclean' in user space. NOTE that 'make mrproper' WILL remove all files which match the pattern *config* or a variation on it. That's why you save your .config before beginning. BTW, I didn't compile the kernel in the end. There was no reason to. Sounds to me like you should do it for the same reason people jump out of airplanes - to see that you can. Start with the top level Makefile and Rules.make, and follow what happens when you run 'make oldconfig; make dep'. Yeah, right. I wanted to install a linmodem driver, not explore the mysteries of makefile, sed and bash, and virtually every possible system file. You want knowledge. I told you where it is found. I have only one explanation for all this: Kernel hackers enjoy the exclusiveness of their status. It's Open Source, but closed society. You want to join it, fine, but you'll have to go through some acceptance tests before you can do anything. No. You'll have to invest effort and show that you know what you are doing. Otherwise, just pay someone to do it for you. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Wed, Feb 19, 2003 at 01:57:39PM +0200, Eli Billauer wrote: So it actually *is* simple, only somehow this is never mentioned. Kernel hackers probably want us to suffer before we can get a working configuration, rather than slightly modifying and already working setup. :-( Actually, the problem of compiling modules out of tree is an acute problem, and it's usually broken in one or another way. Kernel hackers prefer for kernel source to be shipped with the kernel (or as a patch to the kernel source), and every module which doesn't is automatically a step child. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Tue, Feb 18, 2003 at 04:37:29PM +0200, Eli Billauer wrote: 1. What have I done to deserve this? Tried to solve the problem with one hand tied behind your back? (the no recompiling the kernel rule). 2. How can I synchronize between the symbols that I have in usr/src/linux/include/linux/module/ and those that are actually loaded into the kernel? I don't want to recompile the kernel. a. Get the *exact* redhat kernel source rpm for the kernel you are running. b. Copy into the source directory the .config that was used to build that kernel. I think redhat puts the configs under linux/configs/, or they might be under /boot somewhere. c. Run 'make oldconfig; make dep'. This step prepares the intermediary kernel configuration and build files that are needed for the build process. Amongst other things, it handles module version. d. Pray. 3. Most important: Is there any guide around, for free or for $$$, that spares the endless search on the web for solutions? There are plently of one-pagers who tell me to do a lot of make-make-make, but I still haven't found a single guide that tells me, at least, what files are involved. And to what extent every step I take screws the system up. Linux Device Drivers talks about this, but not in sufficient details. You can scourge the linux-kernel mailing list archives, where this subject was discussed repeatedly. You can read the source, where ultimately all questions are answered. Start with the top level Makefile and Rules.make, and follow what happens when you run 'make oldconfig; make dep'. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] root kit lecture
Shachar's lecture of yesterday was very interesting. One thing that I wish we had time to get into in sufficient details is the design, deployment, detection and analysis of Linux rootkits. Anyone wants to pick up the glove and prepare a lecture on the subject? -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Lecture about The Cathedral and the Bazaar Series
Including tomorrow's lecture, we have 5 outstanding lectures. If you add to it another lecture I am working on getting for us, we have 6 lectures in the pipe line. I don't think we need any more lectures for now, especially if they are of the non technical kind. Orr, please keep Apr. 28 open. Lecturer will be from IBM, and topic is TBA. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: OT: PROG question: regarding returning errors in libraries
On Fri, Feb 07, 2003 at 03:18:41PM +0200, guy keren wrote: 3. the function returns the error code by itself (with either a per-function errors enum, or a global list of error codes - with one value for 'success'). this puts consistency into the code (every function that might fail reports an error code) - while making the interface less convinient, when the funciton could sometimes have returned a pointer (e.g. the 'fopen' functoin returns a pointer to a FILE on success, or NULL on failure - and this works because it can report the error code in the global 'errno' variable). I like this mode, and the single project every Linux user uses uses it. You return -ERRNO to signify error, and 0 on success. As for a less convenient, either you pass the 'errno' variable, or the pointer parameter by reference. Another alternative is use the ugly ERR_PTR and PTR_ERR macros, to return a small numeric value (errno) in the high bits of a pointer, when the function returns a pointer. i wonder what people here have to add regarding these models, or regarding other models (again - for the C language) they have used, or wanted to try to use. I've used all three, and the most important issues have been: 1. Always remain consistent. Make sure that all functions return error values in the same range, or use the same value(s) to return an error or success. 2. Global errno is bad, because you might inadvertently change its value by making a different call before checking it. 3. Each function having its own return codes is not consistent, and thus breaks point (1) above. For new code I write (and even old code I have occasion to modify), I always use the kernel's -ERRNO for failure, 0 for success mode. if you comment - please state if you're talking about somehting you used, something you've started using lately, or something you didn't yet use. or if its soemthing you've read about somewhere. and please be fair - i.e. when you describe your magnificent no-problem error reporting system, please also state what are the bad parts of it - where it was annoying, what in it would you improve if you had the time, or if you had an idea how to do, etc. I really dislike the ERR_PTR and PTR_ERR macros mentioned above. If I was rewriting the kernel, I would probably make all those places pass the pointer by reference and return an int. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Aviram Jenik on Network Security
On April 14, at 18:30, Aviram Jenik, CEO of Beyond Security, will give a talk at Haifux. Please let me know which of the following subject you'd prefer to hear: Network Security Basics This basic network security course gives network developers and administrators a quick primer in network security, by showing common attack methods that are used by attackers every day on the Internet, along with some of the common solutions (firewalls, proxies) that are commonly used. Understanding Network Security This course introduces network security and shows the reasons behind the current wave of security holes in the Internet, the ways and tools hackers employ when doing attacks, and the different types of attacks: network level, service level, and application level. The course will also cover Denial-of-Service attacks (DoS and DDoS) and some common solutions that exist to defend against every class of attack. Live demonstrations and examples will be shown during the day. Advanced Network Security - security auditing The course will cover practical ways to perform security auditing in the organization with specific focus on showing and demonstrating common tools, guidelines and so on. The course is intended for a technical audience and will include live demonstrations and in-depth explanations. Advanced Network Security - inside application level attacks Application level attacks are a hot buzzword, but unfortunately not many programmers and software developers are aware of the possible security holes in their applications. This course will show common attack methods such as buffer overflow, SQL injection, cross site scripting, race conditions, and other application-level attacks that are used widely by attackers and are exploitable on almost every known platform and OS. Advanced Network Security - wireless security Wireless communication is considered by security experts to be one of the largest security risks to organizations today. This course will explain and demonstrate the reasons for this inherent insecurity, and show practical ways to secure wireless networks. The course will also discuss the future of wireless security and the upcoming technologies in the field. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] ANN: syscalltrack 0.82 Minty Chinchilla released
syscalltrack-0.82, the 14th alpha release of the Linux kernel system
call tracker, is now available. syscalltrack supports version 2.4.x of
the Linux kernel on the i386 platform.
This release containes several new features, bug fixes and cleanups.
===
New in version 0.82, Minty Chinchilla
---
* This release adds support for matching and logging the current
working directory. I feel that the '%cwd' macro in logging format
is really useful since it allows to know if 'open(passwd, ...)'
relates to '/etc/passwd' rather than '/home/joe/tmp/passwd'. Patch
from Simon Patarin.
* This release allocates the memory for kernel logging buffer using
vmalloc, which allows you to allocate much more memory for them than
the previous version. Patch from Simon Patarin.
* This release contains rewritten serialization/deserialization code
for the rules library. The new code fits better with the overall
design and is cleaner and more robust.
* This release contains a bug fix when detecting whether the kernel
modules are loaded in the user space libraries. Modules should now
be correctly recognized as loaded/unloaded in all cases. Bug spotted
by Mike Shea.
* This release contains a bug fix for sctrace where sctracing a
program with command line arguments could fail to find the program
to trace.
* This release contains several testing improvements, including a new
regression test script, from Orna Agmon.
* This release installs the syscalltrack binaries to
${prefix}/bin/name-version, to allow several syscalltrack versions
to coexist. Kernel modules are installed to
'/lib/modules/kernel-version/syscalltrack-version'.
===
* What is syscalltrack?
syscalltrack is made of a pair of Linux kernel modules and supporting
user space environment which allow interception, logging and possibly
taking action upon system calls that match user defined
criteria. syscalltrack can operate either in tweezers mode, where
only very specific operations are tracked, such as only track and log
attempts to delete /etc/passwd, or in strace(1) compatible mode,
where all of the supported system calls are traced. syscalltrack can
do things that are impossible to do with the ptrace mechanism, because
its core operates in kernel space.
* Where can I get it?
Information on syscalltrack is available on the project's homepage:
http://syscalltrack.sourceforge.net, and in the project's file
release.
The source for the latest version can be downloaded directly from:
http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.82.tar.gz
or any of the other sourceforge mirrors.
* Call for developers:
The syscalltrack project is looking for developers, both for kernel
space and user space. If you want to join in on the fun, get in touch
with us on the syscalltrack-hackers mailing list
(http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).
* License and NO Warranty
syscalltrack is Free Software, licensed under the GNU General Public
License (GPL) version 2. The 'sct_ctrl_lib' library is licensed under
the GNU Lesser General Public License (LGPL).
syscalltrack is in _alpha_ stages and comes with NO warranty. We put
it through extensive testing and routinely run it on our systems, but
if it breaks something, you get to keep all of the pieces.
* PGP Signature
All syscalltrack releases from now on will be signed. This release is
signed with my pgp public key, which you can get from
http://www.mulix.org/pubkey.asc or via
'gpg --keyserver wwwkeys.pgp.net --recv-keys 0xBFD537CB'
Happy syscalltracking!
--
Muli Ben-Yehuda
http://www.mulix.org
http://syscalltrack.sf.net
--
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] ANN: syscalltrack 0.81 Cruel Ducky released
man pages, courtesy of Baruch Even for the debian package of
syscalltrack.
===
Major new features for 0.72 (mostly a bug fix and new syscalls release)
---
* Many new system calls supported, including but not limited to
exit(1), fork(2), read(3) and write(4).
* Fixed bug when evaluating a buffer node and a bug with pattern
matching on a buffer node.
* Fixed bug when matching for a constant [filter_expression {1}] to
return true, as it should, instead of false, as it did.
* Fixed several in-kernel memory leaks and erronous kernel string
handling.
===
Major new features for 0.71 (mostly a bug fix and cleanup release)
--
* add a 'get rule count' and 'get rules' API to to the
sct_ctrl_lib. 'get rule count' will return the number of currently
registered rules, 'get rules' will return to user space from the
kernel a linked list of the before and after rules for each system
call.
* Support for constants when specifying matching rules, for example,
O_RDONLY, O_EXCL and friends for open(2).
* Support for octal/hex numbers in filter expressions.
* Support for specifying and printing multiplex syscall ids as
syscall:func, for example 102:5 for accept(2).
* Assorted internal cleanups, code refactoring, bug fixes and memory
leaks plugged, too many to list here. Documentation and header file
updates. See the ChangeLog for the gory details.
===
Major new features for 0.7
--
* Support for dynamic-cast of 'struct' syscall parameters when filtering
based on them, and for logging. See the relevant section in
doc/sct_config_manual.html for how to use this feature. Mostly useful now
for checking struct parameters in socket calls, so now its possible
to check if a client prorgam tries to connect to a given port or IP address,
etc.
* Support for 'fail syscall' actions - allows you to specify that a matching
syscall invocation will prematurely return a given error code (or '0')
before the system call is actually performed. Handle with care, as failing
the wrong syscall invocations might render your system unuseable. Good
usage example: TODO
* Support for convenience-macros in rule config files. Currently supported
macros include:
- ipaddr(127.0.0.1) - translates an IP address to an unsigned long
in network byte-order.
- htons(7) - host to network byte-order for 'short' numbers.
- usernametoid(root) - translates user name to UID.
- groupnametoid(wheel) - translates group name to GID.
* Experimental Device-driver control support - the syscalltrack kernel module
can now be controlled via a device-file interface - specify -c device_file
when running 'sct_config' to use it. The interface is currently
functionaly-equivalent to the existing 'sysctl' interface - but it will be
enhanced in the future to support logging via a device-file interface,
getting rule list via the device-file interface, etc.
* Support for 'log_format' definition per rule, to override the global
'log_format'.
* Initial correctness-testing script added. Currently only runs 2 tests -
will become more functional on the next release.
* Support for new system calls - waitpid, close and creat.
major bug fixes for version 0.7:
* Fixes for white-space parsing in 'sct_config'.
* Fix small memory leak when deserializing 'log' actions
* Fix bug in the kernel module that would leave dangling function pointers
in case a user cleared only the 'before' function pointer. This bug
wasn't triggered, since sct_config always erased _all_ rules, causing this
code path to remain yet unused.
--
Muli Ben-Yehuda
http://www.mulix.org
http://syscalltrack.sf.net
--
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Small question
On Tue, Jan 21, 2003 at 01:00:14PM +0200, Orr Dunkelman wrote: B) Putting the lecture on a technion server which will broadcast them over the internet. What about (C), putting them up on a world accessible server like fiasco or IGLU? Neither is a viable option right now due to hard disk and bandwidth considerations, but that should improve soon. Before A or B can be accomplished, the lecturers will have to sign some legal forms (as there is a problem of copyright, etc.), in order to allow this. I'll give you a blanket approval form for my lectures when we meet next. -- Muli Ben-Yehuda http://www.mulix.org -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] This week Haifux meeting
On Thu, Jan 16, 2003 at 11:24:26AM +0200, Orr Dunkelman wrote: Next Monday (20/1/3), 18:30, Computer Science bldg. Technion (Taub) lecture room 6, Muli Ben Yehuda is going to talk about Kernel Hacking. Actually, I'm going to talk about Kernel Oopsing, which is like kernel hacking, only in reverse. Lecture slides are now available at http://www.mulix.org/lectures/kernel_oopsing/kernel_oopsing.pdf -- Muli Ben-Yehuda http://www.mulix.org -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] This week Haifux meeting
On Mon, Jan 20, 2003 at 03:23:16PM +0200, Muli Ben-Yehuda wrote: On Thu, Jan 16, 2003 at 11:24:26AM +0200, Orr Dunkelman wrote: Next Monday (20/1/3), 18:30, Computer Science bldg. Technion (Taub) lecture room 6, Muli Ben Yehuda is going to talk about Kernel Hacking. Actually, I'm going to talk about Kernel Oopsing, which is like kernel hacking, only in reverse. Lecture slides are now available at http://www.mulix.org/lectures/kernel_oopsing/kernel_oopsing.pdf Since several people asked: the lecture slides were written in LaTeX, using the prosper (http://prosper.sf.net) style. Spiffy graphics in the comfort of your LaTeX environment. They were presented using 'xpdf -fullscreen foo.pdf' Source is available at http://www.mulix.org/lectures/kernel_oopsing/kernel_oopsing.tex -- Muli Ben-Yehuda http://www.mulix.org -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: IBM Workshop with RMS and T'so in Tel-Aviv and Haifa
On Wed, Dec 18, 2002 at 09:39:02AM +0200, Orna Agmon wrote: The link to the IBM site you gave below doesn't mention January 9th. Looks like that will be more closed event. Or did I missed something? It seems like the TA event is completely open, while the IBM-HAIFA event requires an ID in order to register. There seems to be some confusion in regards to whether the two Yemei Iyoon are the same or different. I'm trying to get confirmation either now, and will post when I know more. The Haifa event, in any case, is on a much smaller scale and I don't know how open it is. -- Muli Ben-Yehuda The speed of light really is too slow nowdays. -- Alan Cox -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] IBM Workshop with RMS and T'so in Tel-Aviv and Haifa
IBM is organizing a GNU/Linux Free Software and Open Source event, to take place on January 8th at Tel Aviv University and January 9th at IBM's Haifa Research Labs[1]. Speaking will be RMS (yesm, yes, *that* Stallman) and Theodore T'so, one of the kernel developers. Details: http://www-5.ibm.com/il/news/events/gnulinux/ Nana story: http://net.nana.co.il/Article/?ArticleID=49331 [1] I work here, if you attend, don't forget to say hi! -- Muli Ben-Yehuda The speed of light really is too slow nowdays. -- Alan Cox -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Summary of Summary of W2L
Discuss. - The Matam lectrue (#0) should not be publicized as part of the W2L series. - The Matam lecture (#0) should be given every semester. - The devtools lectrue (#7) is redundant and should be removed from the series. - Is the Hebrew lecture necessary? if it is, Alon volunteers to give it next time. - If we could make a CD with the hebrew stuff on it and install it at the instaparty, there will be no need for a Hebrew lecture. - In the Introduction lecture (#1), the format in general is good, but we need to be very strict about the times. Absolutely no speaker should speak more than 10 minutes (if the subject is too large, cut it in half). - In #1, the programming demo is cute but not necessary. - The feedback forms need to be redone. Numbers (answers to questions) should be marked on the paper and the respondent should just circle them. - In #1, we need more divrei kishur, to tie the various speakers and subjects together. - Before the lecture begin, inform the speakers and the audience that when the speaker has two minutes left, the moderator will make a sign. When the time is up, the moderator will stand up and wait for the speaker to finish ASAP. - Only has assistants if they're really necessary. If all you need is someone to switch slides, the speaker can do it himself. - The main objective of the feedback forms is to know who is our audience. - For the installation lecture, we *must* have working hardware, preferably a laptop. We should consider installing in a VMWARE virtual machine. - Is the instalaltion lecture necessary, considering how easy modern distros are to install? - We should hand out (sell for the price of the media) cds starting from the first lecture, so people will be able to install on their own. - For the Linux day itself, we should give the basic use lectures at 1600 and 1900. The evening lecture should be given in a lecture hall, to avoid the loud noise in the farm. - We can't have a cd burning unit, we need to have prepared CDs, which are reasonably known to work (burned industrially, not at home). Only burn CDs for people who brought their own media. - The installers should have a refresher course on newer distros, either before the instaparty or in the morning, when it's relatively quiet. - We need to plan in advance the network (hardware, ip addresses, etc) and make sure we have a working, accessible network from the beginning of the day. - We should bring an ADSL modem to make sure ADSL installations work. - We need to announce in advance the ending time, when we won't be admitting any more people. This should be at least an hour before the unofficial ending time. - For the networking lecture, the slides need to be updated. Give less weight to ppp and much more weight to cable/ADSL. Also, mention the networks in the Technion dormitories and how to connect to them. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] emacs power usage(lecture idea)
On Sun, Nov 24, 2002 at 09:56:29AM +, DRYICE wrote: I think an emacs power usage lecture might be of interest. ISTR shlomif wanted such a lecture as well. such a lecture might include: * emacs concepts, how it is built, majorminor modes. * the .emacs initialization script. * some E-lisp. * usefull functions and variables for configuring emacs * how the power user gets help for emacs, finding a function/variable to use. * other stuff. That's a lot of material to cover in one lecture... I have written a small amount of e-lisp for my emacs but there may be some one more qualified than me to give such a lecture(if so speak up). I think you'll do fine. If you want to collaborate on preparing the lecture, I'll be happy to. the questions are: a) will this sort of a lecture intrest you? Aye. b) what should it contain? Cool Stuff(tm) one can do with emacs. c) what would you like emacs to do for you? Coffee. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: emacs power usage(lecture idea)
On Sun, Nov 24, 2002 at 05:21:46PM +0200, Shlomi Fish wrote: Indeed I did. Or rather: how to use Emacs for a long time without losing one's sanity. But, Shlomi, losing one's sanity *is* the path to true emacs enlightenment! And, BTW, what is ISTR? ISTR it means I seem to recall. Coffee. -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ He who re-invents the wheel, understands much better how a wheel works. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] ANN: syscalltrack 0.80 Tanned Otter released
to to the sct_ctrl_lib. 'get rule count' will return the number of currently registered rules, 'get rules' will return to user space from the kernel a linked list of the before and after rules for each system call. * Support for constants when specifying matching rules, for example, O_RDONLY, O_EXCL and friends for open(2). * Support for octal/hex numbers in filter expressions. * Support for specifying and printing multiplex syscall ids as syscall:func, for example 102:5 for accept(2). * Assorted internal cleanups, code refactoring, bug fixes and memory leaks plugged, too many to list here. Documentation and header file updates. See the ChangeLog for the gory details. === Major new features for 0.7 -- * Support for dynamic-cast of 'struct' syscall parameters when filtering based on them, and for logging. See the relevant section in doc/sct_config_manual.html for how to use this feature. Mostly useful now for checking struct parameters in socket calls, so now its possible to check if a client prorgam tries to connect to a given port or IP address, etc. * Support for 'fail syscall' actions - allows you to specify that a matching syscall invocation will prematurely return a given error code (or '0') before the system call is actually performed. Handle with care, as failing the wrong syscall invocations might render your system unuseable. Good usage example: TODO * Support for convenience-macros in rule config files. Currently supported macros include: - ipaddr(127.0.0.1) - translates an IP address to an unsigned long in network byte-order. - htons(7) - host to network byte-order for 'short' numbers. - usernametoid(root) - translates user name to UID. - groupnametoid(wheel) - translates group name to GID. * Experimental Device-driver control support - the syscalltrack kernel module can now be controlled via a device-file interface - specify -c device_file when running 'sct_config' to use it. The interface is currently functionaly-equivalent to the existing 'sysctl' interface - but it will be enhanced in the future to support logging via a device-file interface, getting rule list via the device-file interface, etc. * Support for 'log_format' definition per rule, to override the global 'log_format'. * Initial correctness-testing script added. Currently only runs 2 tests - will become more functional on the next release. * Support for new system calls - waitpid, close and creat. major bug fixes for version 0.7: * Fixes for white-space parsing in 'sct_config'. * Fix small memory leak when deserializing 'log' actions * Fix bug in the kernel module that would leave dangling function pointers in case a user cleared only the 'before' function pointer. This bug wasn't triggered, since sct_config always erased _all_ rules, causing this code path to remain yet unused. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] future lectures
Howdy folks, I see that Orr has scheduled my next two club lectures, Kernel Hacking, 23/12/2002 and Secure Programming, 01/06/2003 If you have any subjects you'd like to be covered in either lecture, let me know. Also, would a lecture sometime later on what's new in the 2.6 (3.0) kernel be of interest? -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? http://www.mulix.org/cv.html -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Reruns and W2L feedback
On Thu, Nov 14, 2002 at 10:50:49PM +0200, Orna Agmon wrote: On Thu, 14 Nov 2002, Muli Ben-Yehuda wrote: That will make it three meetings in three weeks... don't know about you, but I've been looking forward to one meeting every two weeks, with time to rest in between. Also, we'd better do it while the lecture series experience is still fresh. How about before 09/12? when can you make it? ^^ we have Mark's lecture on that date, about clusters. I'll just say since it appears that no one else responded, that I don't have a problem with any date, but I'd prefer earlier rather than later. If orr can't make it earlier, let us make it later. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? http://www.mulix.org/cv.html -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: The Haifux Linux-Day 2003 - Impressions and summarize
On Thu, Nov 07, 2002 at 12:35:39AM +0200, Adir Abraham wrote: Hi all. This wednesday (6/11/2002) we've had an installation party, in Adut area, the Technion. The installation process included Mandrake 9.0 and RedHat 8.0. Many people also inquired about debian and freebsd, and there was a slackware box present as well. The Day started quite calmly, as an installed-person arrived once per 15 or even 20 minutes. It continued like that till 15:00 approximately. At 15:00, though, more people started to arrive, mostly to hear the lectures and to check what's all the mess about, and Meir gave his lecture at 15:30. Unfortunately, Shlomi Fish who was supposed to do the lecture of 12:30pm, did not do it. Nor did Muli, who replaced him, because only one person showed up for it. For future instaparties, we might wish to have two or even three reruns of the lecture in the afternoon and evening. I estimate that approximately 100 people arrived at least to see what's going on (this also includes the installed-persons). Who had loads of fun talking about Linux. You don't have to be an installer or installee to show up and have fun... just... a geek. (no offense intended to anyone, I carry the term proudly). I hope that you've enjoyed the event! I certainly did. A couple of Linux related tips from the weirder problems that we've seen: 1. Always, and I do mean always, run 'tail -f /var/log/messages' in a terminal when debugging a kernel problem. The kernel gives you useful information - use it. An annoying NIC on laptop problem was solved this way - turns out we were trying to load the wrong module for this no name card and it needed 8139too.o instead. 2. SMP kernel crashes during boot with 2.4.18 and 2.4.19 were solved by passing 'noapic' to the kernel during boot. 'single' and 'init=/bin/sh' are very useful as well. That's it, thanks to everyone who showed up, it was great fun. See you again next time! -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? http://www.mulix.org/cv.html -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Re: Linux distributions: A trivial issue?
On Mon, Nov 04, 2002 at 11:48:13AM +0200, Shlomi Fish wrote: Eli, I personally think it is a great idea I, on the other hand, think it's a foolish idea. The essence of Linux is not my distribution is better than yours, or my desktop looks prettier. The essence of Linux is the code, and the things you can do with it. It's the mechanisms, the standards, the code, not the policy - this distribution makes everything convenient for users, and that one compiles everything from scratch. Who cares? No matter which distribution I run, they all do the same things. I couldn't care less which distribution is better, because which distribution I run has infinitesimal bearing on the things I do with it. Therefore, the difference between RH and Mandrake, or Suse and Debian, are of no importance to me. I'd much rather hear about the new technologies in RH 8.0, than about the difference between its desktop theme and mandrake's desktop them, which the discussion you're proposing will ultimately degrade into. IMHO, YMMV, Muli. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? http://www.mulix.org/cv.html -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] assistant for networking lecture needed
Howdy folks, My lovely assistant for the networking lecture has a previous engagement that day, and therefore I am now soliciting volunteers for the job. It's not difficult, and it might even be fun. Let me know if you want it - position is available on a first come first served lock^H^H^H^Hbasis. Thanks, Muli. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? http://www.mulix.org/cv.html -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] hebrew lecture(r) for w2l needed
Salutations, haifux people! Is anyone up to making and delivering a Hebrew in Linux lecture in the upcoming w2l series? If you are, let me know, otherwise, we'll be dropping Hebrew this year due to a lack of lecturer. Thanks, Muli. P.S Tzafrir, could we have your lecture slides from last year? -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? msg00170/pgp0.pgp Description: PGP signature
[Haifux] intro to networking, lecture #5
slides are avalaible at http://www.mulix.org/intro-networking/index.html As always, comments are appreciated. Note that the slides are pretty much the same as last year, which means they're pretty much the same as guy's original slides. Points to ponder: 1. drop ISDN? 2. enlarge the LAN section, including masquerading and firewalls? -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? msg00152/pgp0.pgp Description: PGP signature
[Haifux] Re: Events responsibilities (fwd)
On Wed, Aug 28, 2002 at 07:41:10AM +0300, Orna Agmon wrote: Yesterday we divided most of the responsibilities for lectures and events for w2l. There is a lot of room to fill yourself in and help out. Muli is coordinating the events. For each event, we have/need a coordinator as well as an assistant. 0. pre-series lecture in order to interest technionm students in related courses - 28/10- muli If anyone wants to take this one, I'm not particularly attached to it. Just let me know. 1. Why Linux - 6-7 people explain why Linux is good for you. 30/10 - orna (lecturers: shlomi l, + lecturers needed) If you want to do it, mail me in private. 2. The Installation process. 4/11 - orr 3. 6/11 a. Linux Day - adir and orr b. Basic use of a Linux box (which will be given several times during the day) - shlomif (lecturers needed!) Likewise, mail me in private. 4. Basic admin (su -, rpm install, etc.) 11/11- alon 5. Networking 13/11- muli 6. Hebrew (this lecture might be changed, as most modern distro's are good). 18/11- alon will define the demands from this lecture, coordinator needed. 7. developing tools in the Linux environment - 20/11- muli and guy(?) guy will be doing this one, good. -- calm down, it's *only* ones and zeros. http://syscalltrack.sf.net/ http://vipe.technion.ac.il/~mulix/ msg00056/pgp0.pgp Description: PGP signature
