IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 16 June 2017 (all times are UTC)
| 01:03 | lucascastro has joined IRC (lucascastro!~lucas@170.233.149.62) | |
| 01:56 | mark___ has left IRC (mark___!826921d2@gateway/web/freenode/ip.130.105.33.210, Quit: Page closed) | |
| 02:07 | ||cw has left IRC (||cw!~chrisw@unaffiliated/cw/x-1182934, Quit: Do not follow the null pointer, for therein lies ma&^%#___) | |
| 02:15 | ||cw has joined IRC (||cw!~chrisw@97-87-138-138.dhcp.stls.mo.charter.com) | |
| 02:16 | ||cw has joined IRC (||cw!~chrisw@unaffiliated/cw/x-1182934) | |
| 02:31 | lucascastro has left IRC (lucascastro!~lucas@170.233.149.62, Remote host closed the connection) | |
| 02:31 | lucas_ has joined IRC (lucas_!~lucas@170.233.149.60) | |
| 03:49 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 05:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds) | |
| 05:14 | Statler has joined IRC (Statler!~Georg@p579FFF05.dip0.t-ipconnect.de) | |
| 05:22 | ricotz has joined IRC (ricotz!~ricotz@p5B2A85F3.dip0.t-ipconnect.de) | |
| 05:22 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:13 | Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr) | |
| 06:31 | aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163) | |
| 06:31 | Mark__ has joined IRC (Mark__!826921d2@gateway/web/freenode/ip.130.105.33.210) | |
| 06:32 | aspd has left IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163, Client Quit) | |
| 06:32 | <Mark__> Hi can I use LTSP in gaming? like in cybercafe?
| |
| 06:32 | is this possible?
| |
| 06:37 | <bcg> Mark__: I'm running ltsp on rhel7(-ish). I have my own rpms for that (will be available soon).
| |
| 06:38 | <Mark__> wow nice
| |
| 06:38 | <bcg> I'm been running it on rhel6 for years.
| |
| 06:39 | <Mark__> hows the performance?
| |
| 06:40 | <bcg> What can I say? It depends on your server and network. I'm mostly running localapps-firefox etc on it.
| |
| 06:40 | <Mark__> ok ill be waiting for the release thanks
| |
| 06:42 | <bcg> I will not try to push it to epel anytime soon, but the sources and maybe prebuilt rpms will be available.
| |
| 06:46 | Mark__ has left IRC (Mark__!826921d2@gateway/web/freenode/ip.130.105.33.210, Quit: Page closed) | |
| 06:49 | johnsmith has joined IRC (johnsmith!7ab0043e@gateway/web/freenode/ip.122.176.4.62) | |
| 06:52 | kjackal_ has joined IRC (kjackal_!~quassel@ppp-94-66-56-239.home.otenet.gr) | |
| 06:53 | johnsmith has left IRC (johnsmith!7ab0043e@gateway/web/freenode/ip.122.176.4.62, Ping timeout: 260 seconds) | |
| 07:01 | aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163) | |
| 07:04 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:39 | Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 240 seconds) | |
| 07:46 | v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
| 07:47 | <v4169sgr> Hi All, just a silly question, is there a way of using LTSP with masquerading to run DHCP on a router box with chrooting, to support different thin client architectures from the server? Is this method clearly documented, step by step?
| |
| 07:48 | <alkisg> v4169sgr: errm that's like 3 confused questions into 1
| |
| 07:48 | It's easy to support different thin client architectures, for example see the raspberrypi case:
| |
| 07:49 | !rasbperrypi
| |
| 07:49 | <ltsp> I do not know about 'rasbperrypi', but I do know about these similar topics: 'raspberrypi'
| |
| 07:49 | <alkisg> !raspberrypi
| |
| 07:49 | <ltsp> raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
| |
| 07:49 | <alkisg> #1 there supports i386 and armfh
| |
| 07:49 | *armhf
| |
| 07:49 | Now, that part is completely unrelated to masquerading, so I'm not sure why you mixed those questions...
| |
| 07:49 | <v4169sgr> ok, thanks, it is just simply i686 server and i386 clients, but running DHCP on the router is mandatory
| |
| 07:50 | <alkisg> Why don't you just use i386 for all of them?
| |
| 07:50 | That's what thousands of schools do here...
| |
| 07:50 | !ltsp-pnp
| |
| 07:50 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 07:50 | <v4169sgr> I am indeed, but wondering if i386 on the server is too high a price to pay
| |
| 07:50 | <alkisg> So, if you follow that page, you get an easy ltsp setup with your router as the dhcp server, which supports both i386 and amd64
| |
| 07:50 | No chroots involved at all
| |
| 07:51 | <v4169sgr> yes, actually that is what I am running now
| |
| 07:51 | and it works well
| |
| 07:51 | BUT
| |
| 07:51 | <alkisg> OK, what price are you talking about? 64bit is wasting more ram for 10% more performance, generally not worth it
| |
| 07:51 | <v4169sgr> there are significant performance IO related issues on the server, to do with how i386 handles caching
| |
| 07:52 | <alkisg> Do you have any documentation on that? I've never seen it
| |
| 07:52 | <v4169sgr> I have semi effective workarounds now, but they are only marginally effective
| |
| 07:52 | and don't deal with the issue
| |
| 07:52 | so am wondering about biting the bullet and reinstalling i686
| |
| 07:52 | but need a documented method
| |
| 07:52 | <alkisg> It's strange that I haven't seen such an issue in thousands of installations. Could you elaborate?
| |
| 07:52 | <v4169sgr> so I won't be left high and dry :)
| |
| 07:52 | <alkisg> Some URL or some more documentation?
| |
| 07:53 | Are you talking about disk peformance, for example? How do you measure it?
| |
| 07:54 | E.g. hdparm reports the same speed for disks under 32 or 64bit installations
| |
| 07:54 | <v4169sgr> https://ubuntuforums.org/showthread.php?t=2363087&highlight=
| |
| 07:54 | no, defo not storage perf
| |
| 07:54 | is caching
| |
| 07:55 | no easy answer AFAIK to that
| |
| 07:55 | basically any form of large scale file copying is affected
| |
| 07:55 | or indeed running any form of intensive IO task
| |
| 07:55 | even running a browser for a period
| |
| 07:55 | <alkisg> So you're the only one that seen the issue and the only one that commented on it?
| |
| 07:56 | It sounds like an isolated incident then, similar to what I just reported there: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118
| |
| 07:56 | <v4169sgr> read the thread, there are apparently others with similar issues
| |
| 07:56 | that's where I saw the info about work arounds
| |
| 07:57 | <alkisg> Could you read my bug report, which is shorter, while I read your forum posts?
| |
| 07:57 | Are you talking about the same thing there?
| |
| 07:59 | <v4169sgr> Symptoms are definitely similar, would say it IS related to caching, as workaround to clear the cache provides temporary relief, after operation completes
| |
| 07:59 | was the install you reported on 32 bit?
| |
| 07:59 | <alkisg> Yes, but that's just a detail
| |
| 08:00 | There's math behind it, that depend on ram, bus size etc
| |
| 08:00 | So, it happens with 32bit + 16 ram, it doesn't happen with 32bit + 8 ram,
| |
| 08:00 | and it could happen with 64bit + 8 ram
| |
| 08:00 | <v4169sgr> what about 64 bit + 16 GB ram?
| |
| 08:00 | <alkisg> Haven't tested. It might work by luck.
| |
| 08:00 | Its not a solution, just a combination that happened to work
| |
| 08:01 | So I don't think 64 bit is superior there at all
| |
| 08:01 | <v4169sgr> Do me a favour
| |
| 08:02 | try runningsync && echo "3" | tee /proc/sys/vm/drop_caches
| |
| 08:02 | sync && echo "3" | tee /proc/sys/vm/drop_caches
| |
| 08:02 | on the affected server
| |
| 08:02 | you reported
| |
| 08:02 | after the IO peration
| |
| 08:02 | operation
| |
| 08:02 | <alkisg> I think I tried it many times in the past, but I'll try it again when it happens
| |
| 08:02 | <v4169sgr> and see if it makes a difference
| |
| 08:02 | I think it should
| |
| 08:02 | <alkisg> I've given access to the box, to an ubuntu-kernel developer
| |
| 08:02 | He got the metadata he needed and he'll debug this locally
| |
| 08:03 | <v4169sgr> ok, but is worth trying
| |
| 08:03 | to see if we genuinely have the same issue
| |
| 08:03 | <alkisg> He reports that it's a semi-known problem, that noone knows how to properly solve, so they play with little changes in the config
| |
| 08:03 | OK, you can test with mem=8G in the cmdline too
| |
| 08:03 | This bypasses the issue here
| |
| 08:03 | Which mobo do you have?
| |
| 08:07 | <v4169sgr> Asus P8H77-V LE
| |
| 08:07 | not bleeding edge by any means lol
| |
| 08:07 | and 16 GB RAM
| |
| 08:07 | <alkisg> That's the code he says is to blame: http://elixir.free-electrons.com/linux/latest/source/mm/page-writeback.c
| |
| 08:07 | 16 GB RAM was common to all the cases I've seen it
| |
| 08:07 | Although, I haven't tested with more...
| |
| 08:08 | <v4169sgr> What does mem=8G do? Sorry for the silly question :)
| |
| 08:09 | <alkisg> It tells the kernel to limit your memory to 8GB
| |
| 08:09 | So your system no longer has 16G but 8
| |
| 08:09 | And then it runs fine
| |
| 08:09 | <v4169sgr> Would 12 work too?
| |
| 08:10 | And is this a GRUB option we are talking about?
| |
| 08:10 | have to say this issue remains the major limiting factor in my install atm
| |
| 08:10 | it is most likely to affect user experience on a day to day basis
| |
| 08:11 | and I put in 16 GB RAM to avoid capacity issues when 3 users were all using their thin clients
| |
| 08:11 | as I was seeing previously using 12.04 64 bit and 8 GB RAM
| |
| 08:11 | aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163) | |
| 08:13 | <v4169sgr> According to this link
| |
| 08:13 | https://unix.stackexchange.com/questions/94079/massive-unpredictable-i-o-performance-drop-in-linux
| |
| 08:13 | <aspd> alkisg: Καλημέρα. Έχεις χρόνο να σβήσεις το virt-manager κτλ από τον δικό μου υπολογιστή;
| |
| 08:13 | <v4169sgr> Last Update: After more investigation I've found out that number of files in the cache was triggering the problem. It was trashing the disks while trying to commit many small files back to the disk. Since I was using the system for ten years, I've took the plunge and reinstalled with 64 bit Debian. Now it's working smoothly. It was probably a side effect of ten years of upgrading with finding limits of 32 bit operating system.
| |
| 08:13 | <alkisg> v4169sgr: 12 worked for me for a bit more load, but after a lot of load, it happened again
| |
| 08:13 | aspd: είσαι στο αγγλικό κανάλι πάλι, έλα στο ελληνικό: /join #ts.sch.gr
| |
| 08:15 | v4169sgr: I'll test more with dropping the cache, but I dont think it made a difference in my case. I'm not sure I remember well though.
| |
| 08:15 | Also, I think I was able to reproduce it with plain "dd", without ltsp-update-image or copying a lot of files; just with 1 large file
| |
| 08:15 | Again not sure about that though, it was months ago
| |
| 08:15 | <v4169sgr> yes, I was able to reproduce using file copies to a USB too
| |
| 08:16 | and just simply (a) running unity DE for 24 hours staying logged in, and (b) trying to use google maps on chromium
| |
| 08:16 | and (c) using firefox for an extended period
| |
| 08:17 | impact: system was still usable, just VERY slow
| |
| 08:17 | <alkisg> Have you tested if 64bit fixes the issue?
| |
| 08:17 | <v4169sgr> until whatever task was exited, and the cache dropped
| |
| 08:17 | <alkisg> E.g. with a live cd?
| |
| 08:17 | <v4169sgr> then perf was restored just as though the box was rebooted
| |
| 08:18 | Statler has left IRC (Statler!~Georg@p579FFF05.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 08:19 | <v4169sgr> I can try, probably over the weekend, as system in use right now :)
| |
| 08:32 | aspd has left IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163, Quit: Page closed) | |
| 08:38 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 08:51 | ogra_ is now known as ogra | |
| 08:51 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 08:56 | Statler has joined IRC (Statler!~Georg@mail.lohn24.de) | |
| 09:12 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 09:17 | brendon_ has joined IRC (brendon_!c4d2ae61@gateway/web/freenode/ip.196.210.174.97) | |
| 09:19 | brendon_ has left IRC (brendon_!c4d2ae61@gateway/web/freenode/ip.196.210.174.97, Client Quit) | |
| 09:48 | <alkisg> v4169sgr: dropping the caches seems to help; I'll include that to the bug report. I'll also test with better methods like those mentioned in https://unix.stackexchange.com/questions/253816/restrict-size-of-buffer-cache-in-linux.
| |
| 09:49 | I'm also preparing a one-liner test case, to make things simpler to reproduce...
| |
| 09:53 | Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr) | |
| 10:13 | markus_e92 has left IRC (markus_e92!~markus_e9@91-115-158-50.adsl.highway.telekom.at, Ping timeout: 255 seconds) | |
| 10:14 | markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at) | |
| 10:22 | lucas_ has left IRC (lucas_!~lucas@170.233.149.60, Remote host closed the connection) | |
| 10:24 | <v4169sgr> Thanks alkisg, and well done :) I do hope that your kernel developer friend will find the additional information useful, as it would seem caching does have something to do with it. I am definitely going to test a live CD run of 64 bit 16.04 over the weekend.
| |
| 10:25 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 260 seconds) | |
| 10:25 | <v4169sgr> but of course it is better to fix the issue and remain in 32 bit with a clean well supported line to LTSP-PNP if we can :)
| |
| 10:49 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 10:56 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 10:58 | Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 240 seconds) | |
| 11:07 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 11:10 | lucascastro has joined IRC (lucascastro!~lucas@131.255.227.138) | |
| 12:01 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Remote host closed the connection) | |
| 12:01 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 12:08 | Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr) | |
| 12:30 | v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
| 12:44 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 260 seconds) | |
| 12:46 | <bcg> In ldm's src/plugins/*/Makefile.am you use "ldmplugdir = $(libdir)/ldm/". It should be libexecdir as it is in src/Makefile.am.
| |
| 12:46 | There are few other things too, so I'll create my own repo.
| |
| 12:47 | Or src/Makefile.am should use libdir, whatever you prefer?
| |
| 12:48 | libexecdir = /usr/libexec, libdir = /usr/lib64
| |
| 12:51 | I think it should be libdir.
| |
| 12:58 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 13:54 | lucascastro has left IRC (lucascastro!~lucas@131.255.227.138, Read error: Connection reset by peer) | |
| 13:55 | lucascastro has joined IRC (lucascastro!~lucas@131.255.227.138) | |
| 14:07 | <bcg> alkisg: committed and pushed to ldm-rhel7.
| |
| 14:16 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer) | |
| 14:18 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 14:19 | kjackal_ has left IRC (kjackal_!~quassel@ppp-94-66-56-239.home.otenet.gr, Read error: Connection reset by peer) | |
| 16:00 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Remote host closed the connection) | |
| 16:00 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 16:00 | Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Quit: No Ping reply in 180 seconds.) | |
| 16:02 | Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack) | |
| 16:22 | Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds) | |
| 16:32 | Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr) | |
| 16:36 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 246 seconds) | |
| 16:36 | Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 255 seconds) | |
| 16:40 | jgee has joined IRC (jgee!~jgee@200.118.140.142) | |
| 16:42 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:25 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 17:26 | forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at) | |
| 17:32 | forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Quit: forum) | |
| 17:47 | markus_e92 has left IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 17:51 | markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at) | |
| 18:08 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 18:14 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:33 | gidarakos has joined IRC (gidarakos!59d2e2ad@gateway/web/freenode/ip.89.210.226.173) | |
| 18:41 | gidarakos has left IRC (gidarakos!59d2e2ad@gateway/web/freenode/ip.89.210.226.173, Quit: Page closed) | |
| 18:59 | alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-sghmszqszklenrht, Ping timeout: 264 seconds) | |
| 19:17 | Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection) | |
| 19:55 | Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 268 seconds) | |
| 19:56 | Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack) | |
| 19:57 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 20:40 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 20:50 | <alkisg> bcg: no idea about libexecdirs etc, I haven't written much .c code under linux. sbalneav is the person to ask. Better yet, file bug reports or merge requests so that they can be properly discussed and committed
| |
| 20:51 | 14:07<bcg> alkisg: committed and pushed to ldm-rhel7. => I didn't see any merge requests yet though!
| |
| 20:51 | :)
| |
| 20:55 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:32 | alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-mwctwjhzahnlovgn) | |
| 22:51 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.170.113) | |
| 22:54 | adrianorg has left IRC (adrianorg!~adrianorg@177.204.158.96.dynamic.adsl.gvt.net.br, Ping timeout: 260 seconds) | |
| 23:18 | ltsp` has joined IRC (ltsp`!bot@ltsp.org) | |
| 23:21 | elias_a_ has joined IRC (elias_a_!elias@hilla.kapsi.fi) | |
| 23:21 | syrius__ has joined IRC (syrius__!syrius@thunder.stormtek.net) | |
| 23:21 | TatankaT_ has joined IRC (TatankaT_!~tim@193.190.253.114) | |
| 23:26 | TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split) | |
| 23:26 | syrius has left IRC (syrius!syrius@thunder.stormtek.net, *.net *.split) | |
| 23:26 | lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, *.net *.split) | |
| 23:26 | zamba has left IRC (zamba!marius@flage.org, *.net *.split) | |
| 23:26 | ltsp has left IRC (ltsp!bot@ltsp.org, *.net *.split) | |
| 23:26 | elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split) | |
| 23:26 | zamba has joined IRC (zamba!marius@flage.org) | |
| 23:26 | syrius__ has left IRC (syrius__!syrius@thunder.stormtek.net, Remote host closed the connection) | |
| 23:26 | syrius has joined IRC (syrius!syrius@thunder.stormtek.net) | |
| 23:29 | lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net) | |
| 23:30 | lucascastro has left IRC (lucascastro!~lucas@131.255.227.138, Remote host closed the connection) | |
| 23:31 | syrius has left IRC (syrius!syrius@thunder.stormtek.net, Ping timeout: 260 seconds) | |
| 23:32 | syrius has joined IRC (syrius!syrius@thunder.stormtek.net) | |