January 2011 - syslog-ng - lists.balabit.hu

[Bug 110] New: Advancing the system date and time beyond 2038 causes flood of messages
by bugzilla＠bugzilla.balabit.com 05 Feb '11

05 Feb '11

https://bugzilla.balabit.com/show_bug.cgi?id=110 Summary: Advancing the system date and time beyond 2038 causes flood of messages Product: syslog-ng Version: 2.0.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: gaudet(a)verizon.net Type of the Report: bug Estimated Hours: 0.0 On a 64-bit Linux system (SLES 11 SP1), if the date and time are advanced beyond January 19, 2038 @ 03:14:07, syslog begins flooding the log with MARK messages. It is possible that this is due to the so-called Year 2038 or Unix Millenium bug (see http://www.deepsky.com/~merovech/2038.html) The test: - Set the syslog mark frequency to 2 seconds and restart the syslog service - Tail the log - From another window, set the date to January 19, 2038 @ 03:14:00 - Observe the mark messages are correct until the clock moves beyond 03:14:07 # Display the starting date/time plus seconds since epoch $ date ; date +%s Tue Jan 25 02:10:00 UTC 2011 1295921228 # Set the date and time to January 19, 2038 @ 03:14:00 $ date 011903142038 Tue Jan 19 03:14:00 UTC 2038 # Display the new date/time and note that seconds since epoch have advanced beyond the 32-bit unsigned integer maximum $ date ; date +%s Tue Jan 19 03:14:10 UTC 2038 2147483650 $ tail -f /var/log/messages Jan 25 02:10:00 localhost -- MARK -- Jan 25 02:10:02 localhost -- MARK -- Jan 25 02:10:04 localhost -- MARK -- Jan 25 02:10:06 localhost -- MARK -- Jan 25 02:10:08 localhost -- MARK -- Jan 25 02:10:10 localhost -- MARK -- Jan 25 02:10:12 localhost -- MARK -- Jan 25 02:10:14 localhost -- MARK -- Jan 25 02:10:16 localhost -- MARK -- Jan 25 02:10:18 localhost -- MARK -- Jan 25 02:10:20 localhost -- MARK -- Jan 19 03:14:00 localhost -- MARK -- Jan 19 03:14:00 localhost syslog-ng[4961]: Log statistics; dropped='pipe(/dev/xconsole)=0', dropped='pipe(/dev/tty10)=0', processed='center(queued)=71', processed='center(received)=65', processed='destination(messages)=65', processed='destination(mailinfo)=0', processed='destination(mailwarn)=0', processed='destination(localmessages)=0', processed='destination(newserr)=0', processed='destination(mailerr)=0', processed='destination(netmgm)=0', processed='destination(warn)=2', processed='destination(console)=2', processed='destination(null)=0', processed='destination(mail)=0', processed='destination(xconsole)=2', processed='destination(firewall)=0', processed='destination(acpid)=0', processed='destination(newscrit)=0', processed='destination(newsnotice)=0', processed='source(src)=65' Jan 19 03:14:02 localhost -- MARK -- Jan 19 03:14:04 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- Jan 19 03:14:06 localhost -- MARK -- In a very short period of time, there are thousands of the "Jan 19 03:14:06..." messages in the log. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

tfjson: JSON-generating template function
by Gergely Nagy 05 Feb '11

05 Feb '11

Hi! Looks like the list didn't like me sending the whole patch, so I'll have to omit the patch part this time, and hope that the wall of text below won't hit the size limit. Based on the work of Balint Kovacs <blint(a)balabit.hu>, a $(format_json) template function was implemented: with this function, one can hammer log messages into JSON format. While that is not immediately useful, we have a few things planned that will - with a bit of luck - be able to use this function. The function itself, without arguments, will reformat the log message into JSON. For example, a loggen-generated message will look like this (formatting added by me): { "HOST": "localhost", "HOST_FROM": "localhost", "MESSAGE": "seq: 0000000000, thread: 0000, runid: 1295625842, stamp: 2011-01-21T17:04:02 PADD...", "PROGRAM": "prg00000", "PID": "1234", "SOURCE": "s_tcp", "LEGACY_MSGHDR": "prg00000[1234]: ", ".classifier.class": "unknown" } While this is all cool, there's more! The function accepts parameters: '--select <GLOB>' and '--exclude <GLOB>', where <GLOB> is a shell-like glob pattern. One can have any number of selects or globs. The way this works, is that if a key doesn't match any of the select globs, it will not be included. If it does, but matches any of the exclude globs, it will be dropped. Otherwise it's included. The default select glob is "*", which is why everything is included by default. The globs are matched against the keys: macro names without the dollar sign, patterndb keys, and so on. With this knowledge, we can tweak the template like this: $(format_json --select .classifier.* --select usracct.* --exclude *.*id) Then, given the following message: <86>Jan 21 17:10:21 moria sshd[31930]: pam_unix(sshd:session): session closed for user algernon We'll end up with this JSON: { ".classifier.class": "system", "usracct.username": "algernon", "usracct.type": "logout", "usracct.application": "sshd" } Now, that's not very useful, as we're lacking the HOST and a whole lot of other things. Adding all that as selects would be a bit excessive, therefore one can list macro names (without the dollar sign) along with the select/exclude options, and they'll be included too. Furthermore, one can list key=value pairs, for example, using the log message quite like the one above, and the following template: $(format_json -s .classifier.* -s usracct.* -x *.*id HOST MESSAGE prg='$PROGRAM[$PID]') We'll end up with: { ".classifier.class": "system", "usracct.username": "algernon", "usracct.type": "logout", "usracct.application": "sshd", "MESSAGE": "pam_unix(sshd:session): session closed for user algernon", "prg": "sshd[32216]", "HOST": "localhost" } At the moment, only strings are supported, and there is no way to structure the JSON properly yet. We'll figure out a way to do that too, eventually. There's a few more things in the pipeline for tfjson, so treat this version as a beta. The code is available on the integration/tfjson/base branch of my repository at git://git.madhouse-project.org/syslog-ng/syslog-ng-3.3.git Browsable online at: http://git.madhouse-project.org/syslog-ng/syslog-ng-3.3/tree/modules/tfjson… The bulk of the work was done by Balint, I just happened to accidentally refactor it a tiny bit while reviewing his code. -- |8]

3 4

[RFC]: value-pairs()
by Gergely Nagy 02 Feb '11

02 Feb '11

Hi! The idea of a generic framework to set up value pairs came up first during the afmongodb discussion (see Bazsi's ideas at http://article.gmane.org/gmane.comp.syslog-ng/10432) and while working on the tfjson driver, it came up again. I've learnt a lot since the dynamic-variables implementation in afmongodb, and following Bazsi's comments on the list earlier, we managed to talk a little about the value-pairs() feature too. That, and another quick chat with Balint, followed by working on tfjson helped form the proposal below. I'll divide this into two sections: the first part, mostly aimed at people using syslog-ng in production would be a request for comments regarding the syntax of the feature. The second part will be a few notes on the planned implementation. The Syntax ========== value-pairs ( glob-select ("usracct.*") glob-exclude ("*.*id") builtins (no) $HOST $MESSAGE "program_n_pid" = "$PROGRAM[$PID]" ) What we have here, is basically three possible ways to define - or control - value pairs: * Using a function, like glob-select and glob-exclude or builtins (more about these later) * Macro names, with the '$' sign. * "key" = "value" pairs. The way this is supposed to work is that the base set is all the various key=value pairs syslog-ng collected about a particular log message: the built-in macros ($HOST, $MESSAGE, etc), sdata, patterndb - you name it. This is the set we can select or exclude from, the set we can add new pairs to (different values for each value-pairs() instance, of course). With glob-select(), we can mark a subset of the orignal set for inclusion. Subsequent glob-exclude()s can override this, and remove parts of it from the set. Specifying builtins(no) removes every built-in key from the set. Listing known keys, unquoted, '$' prefixed, will add that value to the set, with the key set to the macro name without the dollar sign. For example, $HOST is exactly the same as "HOST" = "$HOST". Finally, "key" = "value" pairs do the obvious thing: add custom pairs to our set. The order of functions does matter, so glob-select("*") glob-exclude("*id") glob-select("usracct.id") will select usracct.id, but no other key ending with "id". This is partly due to me finding this logical, and because if/when we add other functions later on (say, ltrim() or add-prefix() or similar that modify the keys), the order becomes essential. But, back to the purpose of this all: this would be templating on steroids, so to say. Drivers should be able to easily implement support for value-pairs(), which would make system administrators to tweak the way syslog-ng discovered data will appear in the output. Particularly, this functionality is what will make the afmongodb driver shine. This is a much more advanced version of the dynamic-variables() functionality. This will also come in handy for the JSON template function. I leave the rest up to your imagination. Feedback on the syntax would be most appreciated. The Design ========== Value pairs would be stored in a struct like the following: typedef struct { GPatternSpec *pattern; gboolean exclude; } ValuePairPattern; typedef struct { ValuePairPattern **patterns; gboolean builtins; NVRegistry extras_registry; NVTable extras; } ValuePairs; ValuePairs->patterns would be a NULL terminated array (we can allow for a lot of reallocs during init, imo - otherwise we can make it a GPtrArray or something similar to save time on that), where each pattern is either an exclude or a select pattern. The ->builtins boolean would flag whether we should include the builtin variables ($HOST, etc), and would default to TRUE. And ->extras are the extra keys specified explicitly: both in $MACRO and "key"="value" form (the former translated to "MACRO"="$MACRO" form). We'd have the following support API: ValuePairs *value_pairs_new (); void value_pairs_add_pattern (ValuePairs *vp, const gchar *pattern, gboolean exclude); void value_pairs_set_builtins (ValuePairs *vp, gboolean state); void value_pairs_add_extra (ValuePairs *vp, const gchar *key, const gchar *value); void value_pairs_foreach (ValuePairs *vp, VPForeachFunc *func, gpointer user_data); typedef gboolean (*VPForeachFunc) (const gchar *name, const gchar *value, gssize value_len, gpointer user_data); We'd also have a VALUE_PAIRS keyword in the parser (if it is possible, which I think it is), which drivers could use. The basic VALUE_PAIRS stuff would set up a ValuePairs structure, and store it in a global variable, which the driver could then either copy, or just assign it to it's own (since the main parser won't free or touch it anymore anyway). Then, all the drivers have to do, is call value_pairs_foreach(), which would firs iterate over logmsg_registry's keys, taking the specified patterns into account. Then it would iterate over it's own extras, and pass the results to the foreach function one by one, similar to how nv_table_foreach does. That's about it. It's a bit vague, mostly because I did not research if this is possible the way I imagine it yet. Hopefully this all made at least some sense. -- |8]

5 12

A known syslog-ng issue/bug?
by Xuan Zhong 28 Jan '11

28 Jan '11

Hi, This issue is that if someone looks at a log file generated by syslog-ng with vi, and then “accidentally” writes and saves the file, subsequent writes to the file by syslog-ng don’t appear to work. If syslog-ng closes the file (which happens if it is “idle” for a configurable period, whose default is 1 minute), and then re-opens it when it next needs to write, the writes succeed. Similarly, “service syslog-ng reload” (or restart) will clear the problem. Anyone experienced the similar problem? Thanks Xuan

3 2

Re: [syslog-ng] syslog-ng deadlock if /dev/console locks?
by Patrick H. 26 Jan '11

26 Jan '11

Ah, there might be other differences that you have then. All our machines are almost identical, same OS, only 2 hardware models, same syslog versions, etc, so there wasnt much variance to cause problems. Definitely seems like an HP issue though, and common enough I would have thought something they would have caught and corrected by now :-/ -Patrick Sent: Wed Jan 26 2011 12:55:47 GMT-0500 (Eastern Standard Time) From: Sowell, Brett <brett.sowell(a)amd.com> To: Patrick H. <syslogng(a)feystorm.net> "Krizak, Paul" <Paul.Krizak(a)amd.com>, Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu>, "Petrini, Bryce" <Bryce.Petrini(a)amd.com>, "Hart, Corey" <Corey.Hart(a)amd.com> Subject: Re: [syslog-ng] syslog-ng deadlock if /dev/console locks? > Hi Patrick, > > I had come across your post during research and added the suggested > echo 'h' to our break/recovery test scripts. > > It seemed that, in our case, echoing 'h' to sysrq-trigger would result > in a stable recovery of /dev/console 2/10 times, sometimes temporary > recovery, but more resulted in no effect. > > -Brett > > On 01/26/11 10:17, Patrick H. wrote: >> Nope, just 'echo h', that was it. >> >> -Patrick >> >> Sent: Wed Jan 26 2011 11:16:31 GMT-0500 (Eastern Standard Time) >> From: Paul Krizak <paul.krizak(a)amd.com> >> To: Syslog-ng users' and developers' mailing list >> <syslog-ng(a)lists.balabit.hu> "Patrick H." <syslogng(a)feystorm.net>, >> "Sowell, Brett" <Brett.Sowell(a)amd.com>, "Petrini, Bryce" >> <Bryce.Petrini(a)amd.com>, "Hart, Corey" <Corey.Hart(a)amd.com> >> Subject: Re: [syslog-ng] syslog-ng deadlock if /dev/console locks? >>> Fascinating. So just triggering the kernel to print something to >>> the console (h is "help") caused /dev/console to properly realign >>> and syslog-ng woke back up? You didn't have to restart syslog-ng or >>> reboot the box or anything? >>> >>> >>> Paul Krizak 7171 Southwest Pkwy MS B200.3A >>> MTS Systems Engineer Austin, TX 78735 >>> Advanced Micro Devices Desk: (512) 602-8775 >>> Linux/Unix Systems Engineering Cell: (512) 791-0686 >>> Global IT Infrastructure Fax: (512) 602-0468 >>> >>> On 01/26/11 10:11, Patrick H. wrote: >>>> We ran into this issue when upgrading iLO on all our boxes. When >>>> the iLO >>>> was upgraded, /dev/console went completely unresponsive, and things >>>> started to hang. The solution turned out to be 'echo h > >>>> /proc/sysrq-trigger'. Apparently when the kernel went to write out to >>>> the serial port, it ran into problems and would reinitialize it. After >>>> that everything started working fine. >>>> >>>> -Patrick >>>> >>>> Sent: Wed Jan 26 2011 11:03:37 GMT-0500 (Eastern Standard Time) >>>> From: Sandor Geller <Sandor.Geller(a)morganstanley.com> >>>> To: Syslog-ng users' and developers' mailing list >>>> <syslog-ng(a)lists.balabit.hu> "Sowell, Brett" <Brett.Sowell(a)amd.com>, >>>> "Petrini, Bryce" <Bryce.Petrini(a)amd.com>, "Hart, Corey" >>>> <Corey.Hart(a)amd.com> >>>> Subject: Re: [syslog-ng] syslog-ng deadlock if /dev/console locks? >>>>> Hello, >>>>> >>>>> On Wed, Jan 26, 2011 at 4:12 PM, Paul Krizak<paul.krizak(a)amd.com> >>>>> wrote: >>>>> >>>>>> Hi, we're using syslog-ng 3.1.2 and have run into what appears to >>>>>> be a >>>>>> bug, but I'd like to get the community's opinion before we dig >>>>>> further >>>>>> into it. >>>>>> >>>>>> We have a bunch of HP servers with iLO2 and iLO3 devices, configured >>>>>> with their virtual serial ports on COM1 (ttyS0). We subsequently >>>>>> have >>>>>> the OS (RHEL4, RHEL5) configured to use COM1 as its console (e.g. >>>>>> /dev/console). This is a very standard configuration that allows >>>>>> us to >>>>>> get remote access to the machines without having to purchase the iLO >>>>>> Advanced KVM feature. It also lets us use the Magic SysRq keys >>>>>> to probe >>>>>> dead systems and stuff, so in general it's not something we're >>>>>> keen to >>>>>> change. >>>>>> >>>>>> What we have found, however, is that there are some cases where >>>>>> the iLO >>>>>> will freeze and requires a reboot. When the iLO reboots, >>>>>> however, the >>>>>> kernel's connection to /dev/console (through the virtual serial >>>>>> port) >>>>>> hangs and blocks. Any traffic to /dev/console just sits in the >>>>>> kernel's >>>>>> buffer and is never delivered. Once the buffer is full, the kernel >>>>>> simply blocks on any write to /dev/console. >>>>>> >>>>>> Now this is a Bad Thing in general, and we're working with HP to >>>>>> try and >>>>>> remedy this bug. However, what concerns me is that syslog-ng, when >>>>>> faced with this behavior, also blocks, even for log messages not >>>>>> bound >>>>>> for /dev/console. >>>>>> >>>>> >>>>> syslog-ng uses a single thread (with the exception of database >>>>> destinations) running the event loop so when a read() or a write() >>>>> blocks then it affects the whole log processing >>>>> >>>>> >>>>>> What we have observed is that a system with syslog-ng will keep >>>>>> delivering the occasional console message to /dev/console (ex. >>>>>> *.emerg >>>>>> messages) and meanwhile the file-based log paths keep working. >>>>>> But once >>>>>> /dev/console blocks, the next time a console message is >>>>>> delivered, *all* >>>>>> of syslog-ng blocks waiting for that message to be delivered, and >>>>>> all of >>>>>> the file-based paths block as well. The result is that pretty much >>>>>> everything on the system stops working. For example, you can't >>>>>> log in, >>>>>> even as root, because the login process blocks on the syslog command >>>>>> that writes to /var/log/secure. Anything that uses syslog >>>>>> suddenly blocks. >>>>>> >>>>>> Is this expected behavior? I would think that syslog-ng would be >>>>>> able >>>>>> to continue accepting and delivering messages, even if one of the >>>>>> log >>>>>> paths is stalled on a blocked write. >>>>>> >>>>> >>>>> syslog-ng uses non-blocking I/O for all sources / destinations but >>>>> despite of this the kernel could still block it therefore syslog-ng >>>>> protects reads/writes in logtransport.c with alarm() so it should >>>>> recover when timeout is set and a read/write blocked. For me it looks >>>>> like the timeout is not set in all cases, only file and program >>>>> sources initialise transport->timeout to 10 secs so I'd say this >>>>> isn't >>>>> expected behaviour - it is a bug. >>>>> >>>>> Regards, >>>>> >>>>> Sandor >>>>> ______________________________________________________________________________ >>>>> >>>>> Member info:https://lists.balabit.hu/mailman/listinfo/syslog-ng >>>>> Documentation:http://www.balabit.com/support/documentation/?product=syslog-… >>>>> >>>>> FAQ:http://www.campin.net/syslog-ng/faq.html >>>>> >>>>> >>>

1 0

syslog-ng - Apache Logging
by Steven Shepherd 26 Jan '11

26 Jan '11

I have Apache logging working via a named pipe, however the log looks like: Jan 25 14:44:13 $HOSTNAME $VIRTUAL_HOST: 000.000.000.000 - - [25/Jan/2011:14:44:13 -0600] "GET /foo.html HTTP/1.0" 200 24040 "-" "Wget/1.10.2 (Red Hat modified)" I want to strip the syslog timestamp and $HOSTNAME. However, if I use "template("$MSGONLY\n")", it strips the timestamp, hostname *and* the $virtual_host (obtained from including "%V" in LogFormat and using 'vcommon' on apache server). Any ideas on how to remove the syslog data but leave the vhost data in place? Cheers!

2 2

Problem with getting syslog-ng statistics
by Aleksei Plotnikov 25 Jan '11

25 Jan '11

Hello everyone, I have a problem with getting statistics from syslog-ng 3.0.5 (under Debian 5.0.4) using it's socket file. In our configuration logs received by syslog-ng are being forwarded to python scripts (which in turn send logs to database). Since sometimes these scripts cannot handle the load, we want to monitor syslog-ng statistics for dropped logs. Currently, I run a script from cron which get statistics from syslog-ng socket file like this "echo STATS | socat - /var/lib/syslog-ng/syslog-ng.ctl" and then parse output. Most of time it works great, but during peak times when number of logs get higher ( ~2000 logs/sec instead of ~1500 logs/sec), this cron script cannot get any output from statistics. Also this message appears in /var/log/syslog: syslog-ng[21677]: Error writing control channel; error='Broken pipe (32)' Is it possible to tune syslog-ng statistics somehow, or maybe there is a better way to get statistics? Thanks, Aleksei ---------------------------- Võimalik, et oled TASUTA 1600€ soojamaareisist vaid CV sisestamise kaugusel! Vaata lähemalt SIIT. http://www.cv.ee

2 2

AUTO: Shanif Lakhani is out of the office (returning 02/14/2011)
by Shanif Lakhani 25 Jan '11

25 Jan '11

I am out of the office until 02/14/2011. Please contact Robert Holoweckyj and/or Lori-Ann Walker for any urgent matters. Thanks Note: This is an automated response to your message "syslog-ng Digest, Vol 69, Issue 44" sent on 1/24/11 20:55:19. This is the only notification you will receive while this person is away.

1 0

[review request]: MongoDB destination
by Gergely Nagy 24 Jan '11

24 Jan '11

I prepared three branches, in preparation for a pull request, but there's still some minor work left to do, so this is more like a "review the structure and plan before the pull request, please" request. All three branches are integration branches, and as such, I will rebase them from time to time. All three branches are folded into one commit over their base, signed-off, and should have proper descriptions. * integration/libmongo-client This one adds a git submodule, which pulls in the libmongo-client library from github to modules/afmongodb/libmongo-client. Also adds infrastructure to make autogen.sh, configure and make enter this directory and Do The Right Thing. At the moment, linking with the supplied libmongo-client is the only option, because the library is not yet ready for system-wide install. It is easy to extend this framework to use the system library if it exists - that is one of the missing features which should go into this branch, but isn't there yet. * integration/afmongodb/base This is the basic, bare-bones driver, without support for dynamic values: it depends on the previous one, and doesn't change anything outside of modules/afmongodb/, except lib/stats.[ch], where it adds SCS_MONGO for stat counter support. The current state of the driver is reasonably stable, there are three known problems that I am aware of: + Segfaults whenever the writer thread emits an msg_debug() or similar itself. This is actually a bug in ivykis, for which Bazsi had a fix for, but I can't find the fix in his git tree yet (only the log message, but without the patch). + Locking issues: it's fairly easy to push the driver into a deadlock, where it will just sit and wait, not doing a thing. I've only seen this happen with flow-control enabled, though. This will have to be solved before I'm confident enough to ask for a pull. + The libmongo-client library is built as a shared library, and is installed as such. It should be static-only, and not installed, only linked to afmongodb. This will be implemented mostly in libmongo-client, and an update of the integration/libmongo-client branch will pull that in; then this branch will be updated accordingly. * integration/afmongodb/dyn-vars Based on integration/afmongodb/base, this adds dynamic_values() support. Minor modifications are done to nvtable too, but it's a very small patch, and very straightforward too. However, as discussed earlier, the goal in the long run is to develop a generic framework for this kind of thing, so this here is more like a temporary solution so that people can experiment with the key feature the mongodb provides over the others. Until the generic framework is ready, this, I believe, is an acceptable compromise. -- |8]

2 2

Error starting syslog-ng
by Fabien Bagard 24 Jan '11

24 Jan '11

Hi list ! I have a problem to start syslog-ng. I got a syntax error on line in bold : ###### # sources # all known message sources source s_all { # message generated by Syslog-NG internal(); # standard Linux log source (this is the default place for the syslog() # function to send logs to) unix-stream("/dev/log"); # messages from the kernel file("/proc/kmsg" log_prefix("kernel: ")); }; source s_unix { tcp( port(514) * tls(* key_file("/etc/syslog-ng/certs/logger.parrot.biz.key") cert_file("/etc/syslog-ng/certs/logger.parrot.biz.crt") ca_dir("/etc/syslog-ng/certs/CA/") peer_verify(optional-untrusted) ) ); }; But I can't figure out what ! Can someone point this error to me ? Thanks -- Fabien Bagard IT Department tel + 33 (0)1 48 03 60 40 -------------------------------------------------------------------------------- Parrot SA 174, Quai de Jemmapes | 75010 Paris - France tel + 33 (0)1 48 03 60 60 | fax + 33 (0)1 48 03 70 08 http://www.parrot.com -------------------------------------------------------------------------------- This e-mail message and any attached document(s) are for the sole use of the intended recipient(s)and may contain confidential and legally privileged information. Any unauthorized review, copy, use and/or disclosure is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original.

4 9