On Tue, Jul 8, 2014 at 2:16 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 08.07.2014 17:58, schrieb Les Mikesell:
On Tue, Jul 8, 2014 at 8:42 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax.
Sorry, but I'd recommend that anyone who thinks shell syntax is 'messy' just stay away from unix-like systems instead of destroying the best parts of them
WTF - you can place a shell-script in ExecStart and set type to 'oneshot' - nobody is taking anything away from you
Unless you are offering to do that for me, for free, on all my systems, having to do it certainly does take something away.
Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.
What part of i/o redirection does the shell not handle well for you?
wtaht part of monitoring did you not understand?
Generally speaking, if a service is broken to the point that it needs something to automatically restart it I'd rather have it die gracefully and not do surprising things until someone fixes it. But then again, doesn't mysqld manage to accomplish that in a fully-compatible manner on Centos6?
Les Mikesell <lesmikesell@...> writes:
On Tue, Jul 8, 2014 at 2:16 PM, Reindl Harald <h.reindl@...> wrote:
Am 08.07.2014 17:58, schrieb Les Mikesell:
On Tue, Jul 8, 2014 at 8:42 AM, Dennis Jacobfeuerborn <dennisml@...> wrote:
Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax.
Sorry, but I'd recommend that anyone who thinks shell syntax is 'messy' just stay away from unix-like systems instead of destroying the best parts of them
WTF - you can place a shell-script in ExecStart and set type to 'oneshot' - nobody is taking anything away from you
Unless you are offering to do that for me, for free, on all my systems, having to do it certainly does take something away.
Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.
What part of i/o redirection does the shell not handle well for you?
wtaht part of monitoring did you not understand?
Generally speaking, if a service is broken to the point that it needs something to automatically restart it I'd rather have it die gracefully and not do surprising things until someone fixes it. But then again, doesn't mysqld manage to accomplish that in a fully-compatible manner on Centos6?
Can't find the original post so replying and agreeing with Les. Have the same ongoing problem with radvd. When My IPv6 tunnel provider burps, the tunnel drops. The tunnel daemon usually reconnects but radvd stays down. Solution:
*/12 * * * * /sbin/service radvd status > /dev/null 2>&1 || /sbin/service radvd start 2>&1
in crontab. How hard is that? And without all of the systemd nonsense.
Cheers, Dave
On 07/10/2014 09:39 AM, David G. Miller wrote:
Can't find the original post so replying and agreeing with Les. Have the same ongoing problem with radvd. When My IPv6 tunnel provider burps, the tunnel drops. The tunnel daemon usually reconnects but radvd stays down. Solution:
*/12 * * * * /sbin/service radvd status > /dev/null 2>&1 || /sbin/service radvd start 2>&1
in crontab. How hard is that? And without all of the systemd nonsense.
That, my friend, is a textbook example of a kluge.
On Thu, Jul 10, 2014 at 8:39 AM, David G. Miller dave@davenjudy.org wrote:
Generally speaking, if a service is broken to the point that it needs something to automatically restart it I'd rather have it die gracefully and not do surprising things until someone fixes it. But then again, doesn't mysqld manage to accomplish that in a fully-compatible manner on Centos6?
Can't find the original post so replying and agreeing with Les. Have the same ongoing problem with radvd. When My IPv6 tunnel provider burps, the tunnel drops. The tunnel daemon usually reconnects but radvd stays down. Solution:
*/12 * * * * /sbin/service radvd status > /dev/null 2>&1 || /sbin/service radvd start 2>&1
in crontab. How hard is that? And without all of the systemd nonsense.
Or, if you want things to respawn, the original init handled that very nicely via inittab. Also,running a shell as the parent of your daemon as a watchdog that can repair its environment and restart it if it exits doesn't have much overhead. Programs share the loaded executable code across all instances and you pretty much always have some shells running on a linux/unix box - a few more won't matter.
Les Mikesell <lesmikesell@...> writes:
On Thu, Jul 10, 2014 at 8:39 AM, David G. Miller <dave@...> wrote:
Generally speaking, if a service is broken to the point that it needs something to automatically restart it I'd rather have it die gracefully and not do surprising things until someone fixes it. But then again, doesn't mysqld manage to accomplish that in a fully-compatible manner on Centos6?
Can't find the original post so replying and agreeing with Les. Have the same ongoing problem with radvd. When My IPv6 tunnel provider burps, the tunnel drops. The tunnel daemon usually reconnects but radvd stays down. Solution:
*/12 * * * * /sbin/service radvd status > /dev/null 2>&1 || /sbin/service radvd start 2>&1
in crontab. How hard is that? And without all of the systemd nonsense.
Or, if you want things to respawn, the original init handled that very nicely via inittab. Also,running a shell as the parent of your daemon as a watchdog that can repair its environment and restart it if it exits doesn't have much overhead. Programs share the loaded executable code across all instances and you pretty much always have some shells running on a linux/unix box - a few more won't matter.
Just pointing out one of several approaches to respawning a daemon without the overhead of systemd. I went with this approach since the problem is not with radvd or its init script but with my IPv6 tunnel provider. I wanted something that didn't require modifying any of the installed bits. This approach also means that updates to radvd and friends don't overwrite my modifications. Just "playing with" the IPv6 stuff so having it down for up to five minutes also isn't a problem. The source of the problem goes away when my ISP provides IPv6 and I don't need to tunnel IPv6 in IPv4 anymore.
I look at systemd as being yet another nuclear fly swatter. Overkill for simple problems that can and should be be addressed at the problem without a sweeping, system level change.
Cheers, Dave
[I wasn't going to reply; but after thinking about it for quite a while, there are a few points here that deserve just a bit of level-headed attention.]
On 07/11/2014 10:53 AM, David G. Miller wrote:
Les Mikesell <lesmikesell@...> writes:
Or, if you want things to respawn, the original init handled that very nicely via inittab.
Replying to Les' comment: the original inittab respawn method is completely brain-dead, blindly respawning without any thought for what conditions might need to be checked, etc.
Just pointing out one of several approaches to respawning a daemon without the overhead of systemd.
Replying to David: So you'd prefer the overhead of cron plus shells plus a bit of arcane syntax? When I first replied to this crontab line, I honestly thought you were being tongue-in-cheek.
I have a similar sort of kluge in place, on a CentOS 6 system at a client, that uses the autossh package to hold open ssh reverse tunnels; reverse tunnels are great when the client's machine is behind a known-to-change-frequently dynamic address.
I went with this approach since the problem is not with radvd or its init script but with my IPv6 tunnel provider.
Sounds like something that systemd's concept of process dependencies could solve for you with an easier (and non-executable) syntax. Systemd provides an 'OnFailure' directive that allows you to do whatever you'd like upon failure of an particular 'unit.' That sort of mechanism might allow you to implement the process equivalent of Cisco IOS' IP SLA's. (You could mount /etc (and /var) noexec and have /usr and friends mounted read-only, even.)
I wanted something that didn't require modifying any of the installed bits.
This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' to systemd will override the OS installed ones, and are all collected together in one well-defined and standard place.
This approach also means that updates to radvd and friends don't overwrite my modifications.
This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' for systemd will not be touched by the updates to the OS-supplied ones.
Just "playing with" the IPv6 stuff so having it down for up to five minutes also isn't a problem. The source of the problem goes away when my ISP provides IPv6 and I don't need to tunnel IPv6 in IPv4 anymore.
If you can figure out IPv6 then systemd should be no sweat.
I look at systemd as being yet another nuclear fly swatter. Overkill for simple problems that can and should be be addressed at the problem without a sweeping, system level change.
I have done all of the various init styles at various times, so I make this statement having 27 years of experience dealing with Unix-like systems (I won't bore anyone with the list): in my quick perusal of systemd and its documentation, I'm cautiously optimistic that maybe finally we have something that a sysadmin can really make sing. Time will tell, of course, whether systemd actually addresses the core problems or not; we've already had one round of an init replacement, Upstart, that didn't succeed in fully addressing the core problems (but will be with us until 2020 as part of EL6). And I always reserve the right to be wrong.
But traditional SystemV init last appears in EL5, which, while it is still supported until 2017, is two major versions old at this point. And in case you missed the announcement from Red Hat, EL5.11 is the last minor version update of EL5, with subsequent updates being released as they come and not batched into point releases. (I now know my last targeted version for IA64 rebuilding, which is good.....as long as I can put in some automation to grab updates from then on).
Am 12.07.2014 um 17:08 schrieb Lamar Owen lowen@pari.edu:
[I wasn't going to reply; but after thinking about it for quite a while, there are a few points here that deserve just a bit of level-headed attention.]
On 07/11/2014 10:53 AM, David G. Miller wrote:
Les Mikesell <lesmikesell@...> writes:
Or, if you want things to respawn, the original init handled that very nicely via inittab.
Replying to Les' comment: the original inittab respawn method is completely brain-dead, blindly respawning without any thought for what conditions might need to be checked, etc.
That’s probably true.
But still, I believe that much of the complexity of systemd (that it apparently has) comes from the fact that it’s most intended to provide a „smooth“ desktop experience.
Now, it looks like almost everything is a „service“.
Can I pick an example?
[root@ipa ~]# systemctl list-unit-files |grep ssh sshd-keygen.service static sshd.service enabled sshd@.service static sshd.socket disabled
What is the difference between sshd.service and sshd@.service? Am I right in assuming that the sshd-keygen.service is responsible for creating the initial host-keys?
I may be wrong, but sshd works nice on my 100+ servers without a special service for this. In fact, I loathed the Solaris-behavior, where you had to „refresh“ the service for this (or something to this effect) On FreeBSD, if I want to create new keys, I delete the old ones and restart the service. I very rarely need that, so I just assume it’s the same on RHEL.
Can anyone give an example from a stock RHEL7 install that could not have been done with a traditional SysV-init?
On 07/12/2014 11:08 AM, Lamar Owen wrote:
[I wasn't going to reply; but after thinking about it for quite a while, there are a few points here that deserve just a bit of level-headed attention.]
On 07/11/2014 10:53 AM, David G. Miller wrote:
Les Mikesell <lesmikesell@...> writes:
Or, if you want things to respawn, the original init handled that very nicely via inittab.
Replying to Les' comment: the original inittab respawn method is completely brain-dead, blindly respawning without any thought for what conditions might need to be checked, etc.
Just pointing out one of several approaches to respawning a daemon without the overhead of systemd.
Replying to David: So you'd prefer the overhead of cron plus shells plus a bit of arcane syntax? When I first replied to this crontab line, I honestly thought you were being tongue-in-cheek.
I have a similar sort of kluge in place, on a CentOS 6 system at a client, that uses the autossh package to hold open ssh reverse tunnels; reverse tunnels are great when the client's machine is behind a known-to-change-frequently dynamic address.
I went with this approach since the problem is not with radvd or its init script but with my IPv6 tunnel provider.
Sounds like something that systemd's concept of process dependencies could solve for you with an easier (and non-executable) syntax. Systemd provides an 'OnFailure' directive that allows you to do whatever you'd like upon failure of an particular 'unit.' That sort of mechanism might allow you to implement the process equivalent of Cisco IOS' IP SLA's. (You could mount /etc (and /var) noexec and have /usr and friends mounted read-only, even.)
I wanted something that didn't require modifying any of the installed bits.
This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' to systemd will override the OS installed ones, and are all collected together in one well-defined and standard place.
This approach also means that updates to radvd and friends don't overwrite my modifications.
This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' for systemd will not be touched by the updates to the OS-supplied ones.
Just "playing with" the IPv6 stuff so having it down for up to five minutes also isn't a problem. The source of the problem goes away when my ISP provides IPv6 and I don't need to tunnel IPv6 in IPv4 anymore.
If you can figure out IPv6 then systemd should be no sweat.
I look at systemd as being yet another nuclear fly swatter. Overkill for simple problems that can and should be be addressed at the problem without a sweeping, system level change.
I have done all of the various init styles at various times, so I make this statement having 27 years of experience dealing with Unix-like systems (I won't bore anyone with the list): in my quick perusal of systemd and its documentation, I'm cautiously optimistic that maybe finally we have something that a sysadmin can really make sing. Time will tell, of course, whether systemd actually addresses the core problems or not; we've already had one round of an init replacement, Upstart, that didn't succeed in fully addressing the core problems (but will be with us until 2020 as part of EL6). And I always reserve the right to be wrong.
But traditional SystemV init last appears in EL5, which, while it is still supported until 2017, is two major versions old at this point. And in case you missed the announcement from Red Hat, EL5.11 is the last minor version update of EL5, with subsequent updates being released as they come and not batched into point releases. (I now know my last targeted version for IA64 rebuilding, which is good.....as long as I can put in some automation to grab updates from then on).
Hi Lamar,
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
+ $ 10.00 :-)
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
-- Regards,
Paul. England, EU.
Centos, Exim, Apache, Libre Office. Linux is the future. Micro$oft is the past.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2014-07-14 at 07:18 -0500, William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
There is an old English saying "Never put all your eggs in the same basket."
If systemd has a bug or is exploited, because it does so many different things, the resulting "damage" to a working system is potentially significantly greater than if systemd did less functions. As previously stated by JH, its in RH so its in Centos. We have to accept it or go elsewhere.
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
mark
Like OpenSSL ?
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
William Woods wrote:
Please stop top posting.
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
Like OpenSSL ?
I suggest you google with the following search criteria: "windows server" exploits
mark
On Jul 14, 2014, at 10:19 AM, m.roth@5-cent.us wrote:
William Woods wrote:
Please stop top posting.
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
Like OpenSSL ?
I suggest you google with the following search criteria: "windows server" exploits
mark
Sigh, nothing like a zealot. ALL OS’s have vulns and exploits, no matter what you decide to believe.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/14/2014 11:26 AM, William Woods wrote:
On Jul 14, 2014, at 10:19 AM, m.roth@5-cent.us wrote:
William Woods wrote:
Please stop top posting.
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
> Having been working with UNIX like systems since 1985 > my biggest complaint with systemd is it so intrusive, it wants to be > everything which makes > it vulnerable to bugs and exploits - umm.. like Windoze! > My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
Like OpenSSL ?
I suggest you google with the following search criteria: "windows server" exploits
markSigh, nothing like a zealot. ALL OS's have vulns and exploits, no matter what you decide to believe.
Sigh, nothing like someone who is in a constant state of deniability.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Jul 14, 2014 at 10:19 AM, m.roth@5-cent.us wrote:
William Woods wrote:
Please stop top posting.
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
Having been working with UNIX like systems since 1985 my biggest complaint with systemd is it so intrusive, it wants to be everything which makes it vulnerable to bugs and exploits - umm.. like Windoze!
My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
Like OpenSSL ?
I suggest you google with the following search criteria: "windows server" exploits
mark
Are you really trying to win the thread with "but omg windows!"? All software is swiss cheese, the only really secure software is turned off. Windows is no more or less secure than anything else out there.
OpenSSL is sadly an excellent example of that.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Jul 14, 2014, at 11:19 AM, Andrew Wyatt andrew@fuduntu.org wrote:
On Mon, Jul 14, 2014 at 10:19 AM, m.roth@5-cent.us wrote:
William Woods wrote:
Please stop top posting.
On Jul 14, 2014, at 9:48 AM, m.roth@5-cent.us wrote:
William Woods wrote:
On Jul 14, 2014, at 7:15 AM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 06:42 -0400, Steve Clark wrote:
> Having been working with UNIX like systems since 1985 > my biggest complaint with systemd is it so intrusive, it wants to be > everything which makes > it vulnerable to bugs and exploits - umm.. like Windoze!
> My $.02
- $ 10.00 :-)
Because UNIX has never had a bug or exploit right ?
Well... we know that > 50% of the Web and 'Net runs on Linux and other unices. Compare and contrast the number of Windows Server vulnerabilities that have been exploited to those of *Nix... and, for extra credit, how fast they were admitted, and fixed.....
Like OpenSSL ?
I suggest you google with the following search criteria: "windows server" exploits
markAre you really trying to win the thread with "but omg windows!"? All software is swiss cheese, the only really secure software is turned off. Windows is no more or less secure than anything else out there.
OpenSSL is sadly an excellent example of that.
I was going to bring up OpenSSL but…..yea that.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2014-07-14 at 11:19 -0500, Andrew Wyatt wrote:
Windows is no more or less secure than anything else out there.
Not with so many of Windoze world-wide users getting viruses all the time. Centos is inherently more secure than Windoze.
Always Learning wrote:
On Mon, 2014-07-14 at 11:19 -0500, Andrew Wyatt wrote:
Windows is no more or less secure than anything else out there.
That is a false statement.
Not with so many of Windoze world-wide users getting viruses all the time. Centos is inherently more secure than Windoze.
Yup.
mark
On Mon, Jul 14, 2014 at 2:58 PM, Always Learning centos@u62.u22.net wrote:
On Mon, 2014-07-14 at 11:19 -0500, Andrew Wyatt wrote:
Windows is no more or less secure than anything else out there.
Not with so many of Windoze world-wide users getting viruses all the time. Centos is inherently more secure than Windoze.
I would argue that also has to do with the average windows. You know, the human engineering part of being attacked ("Your computer is infected! The red blinking light says so! Click here to install our 'sheep-me' program, making sure to run it as an admin user!")
-- Regards,
Paul. England, EU.
Centos, Exim, Apache, Libre Office. Linux is the future. Micro$oft is the past.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Always Learning -
Andrew Wyatt -
David G. Miller -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Mauricio Tavares -
Rainer Duffner -
Steve Clark -
William Woods