Bit Twister skrev:
> On Wed, 13 Aug 2008 23:50:56 +0200, Roger wrote:
>> Ok, thanks a lot for your time....both of you. I have just returned from
>> night-shift, and will try to explain a little.
>> My eth0 (on-board) is connected on the "backside" of the machine,
>> towards my wannabe private lan. The router there, a D-link dir-100 have
>> 192.165.0.1 as ip-adress. My Wifi-card (ath0) have 192.168.0.198 as
>> ip-adress and is connected to a wireless router,192.168.0.1 witch is
>> connected to my ISP.
>> In the weekend, I will set eth0 to static, and tinker a little with the
>> settings given me here.
>>
>> 0Ã¥ 1:av...Norwegian. PÃ…=ON AV=OFF =)
>>
>> Sorry if I have been unclear in anything.
>
> Question, is nodex going to use both wifi and eth0 or just eth0?

just eth0


--
Mandriva Linux 2008.1 pwp (Linuxcounter #432950)

MSI K8TM, 1,0 Gb Memory, AMD Sempron 3000+ CPU
ATI Sapphire Radeon X1600
__________________________________________________
Be against others the way
you want to be treated yourself

On Thu, 14 Aug 2008 00:20:00 +0200, Roger wrote:
> Bit Twister skrev:
>>
>> Question, is nodex going to use both wifi and eth0 or just eth0?
>
> Just eth0

Ok, then the /etc/sysctl.conf change on filserver will be needed to
route nodex packets through to the Internet.

Bit Twister writes:

>On Wed, 13 Aug 2008 21:17:44 GMT, Unruh wrote:
>> Bit Twister writes:
>>
>>>On Wed, 13 Aug 2008 18:02:54 GMT, Unruh wrote:
>>>> Bit Twister writes:
>>>>
>>>> No
>>>> rm /etc/rc{3,5}.d/*avahi*
>>>> should do fine.
>>
>>>Unless, you happen to go through the Services GUI in MCC and click Ok.
>>>And at least a security level 3, K/S* links will be rebuilt from
>>>/etc/init.d/ scripts headers weekly IIRC.
>>
>> Erasing it is fine unless you reinstall it. Yes, I agree. But why in the
>> world would you reinstall it?

>Did not say I erased /etc/init.d/jexec, I pretty sure it would come
>back during an update.

No, I said erase it. You said that if you ran the SErvices gui in MCC and
told it to install the service again, then that service would again be
installed. I agree. So do not do that.



>> If security level 3 does that then that is yet another reason to stay as
>> far away as possible from level 3

>Does not matter about level 3, Service GUI screen seemed to put links
>back after clicking OK.

It also tells gives you the option of setting which services are running
and which not. If you click OK when it tells you that it is going to run
that service, then the result does not surprise me.



>> Yes, or if the 198 confuses him, use 10.x.x.x

>Since some ISPs use the 10.x.x.x network to manage their customer
>equipment, I would not recommend it just to keep everyone honest.

????

Roger writes:

>Ok, thanks a lot for your time....both of you. I have just returned from
>night-shift, and will try to explain a little.
>My eth0 (on-board) is connected on the "backside" of the machine,
>towards my wannabe private lan. The router there, a D-link dir-100 have
>192.165.0.1 as ip-adress. My Wifi-card (ath0) have 192.168.0.198 as

Please please change that eth zero IP address. Unless your DLink is
connected an outside service provider, do NOT use a public address for it.
Ie it shoul dNOT be 192.165.0.1. Use 192.168.10.1 if you want, or 10.0.0.1
but not some publick IP.

>ip-adress and is connected to a wireless router,192.168.0.1 witch is
>connected to my ISP.

OK, so that is the ONLY default route you should have

route -n
should have ONLY ONE line starting with 0.0.0.0 and the next entry should
be 192.168.0.1


>In the weekend, I will set eth0 to static, and tinker a little with the
>settings given me here.

eth0 being static makes things a bit simpler but is not the problem

By the way, what is your ISP's address? Ie, are they on the 192.165.x.x
address list?



>0å 1:av...Norwegian. PÅ=ON AV=OFF =)

>Sorry if I have been unclear in anything.

>All the best

>Roger


>--
> Mandriva Linux 2008.1 pwp (Linuxcounter #432950)

> MSI K8TM, 1,0 Gb Memory, AMD Sempron 3000+ CPU
> ATI Sapphire Radeon X1600
> __________________________________________________
> Be against others the way
> you want to be treated yourself

On Wed, 13 Aug 2008 22:37:40 GMT, Unruh wrote:

> No, I said erase it. You said that if you ran the SErvices gui in MCC and
> told it to install the service again, then that service would again be
> installed. I agree. So do not do that.

> It also tells gives you the option of setting which services are running
> and which not. If you click OK when it tells you that it is going to run
> that service, then the result does not surprise me.

There is a misunderstanding there. You change any service in MCC
all services are relinked based on ON Boot value/setting in GUI.

No need to change jexec. Any service changed will reset all links.

On Wed, 13 Aug 2008 22:41:52 GMT, Unruh wrote:

> By the way, what is your ISP's address? Ie, are they on the 192.165.x.x
> address list?

Using the OP's Internet ip address,

$ whois 193.216.109.44
inetnum: 193.216.109.0 - 193.216.109.255
netname: TELE2-ADSL-DYNAMIC1
descr: Tele2 Norge AS. Dynamic IP pool for BAP 0506

On Wed, 13 Aug 2008 19:42:46 -0400, David W. Hodgins wrote:
> On Wed, 13 Aug 2008 18:53:39 -0400, Bit Twister wrote:
>
>> No need to change jexec. Any service changed will reset all links.
>
> It isn't drakxservices that keeps turning on jexec. I just turned
> it of again, then made another change using drakxservices, (after
> restarting it), and it isn't turned back on. I haven't found
> anything obvious anywhere in /lib, /usr, or /etc, that is causing
> it.

This part of the subthread was only about the K/S* links being recreated
when you change any service.

> If something were doing a chkconfig reset, or chkconfig on, for
> every package, there would be massive problems.

Yes, I agree.

drakxservices will set all the S* links for each service if it is On
as displayed in the gui screen when you change any service and click Ok.

I did not say all services would go On.


> It's only jexec that this seems to be happening with.

When jexec first came out, I keep seeing it running after a boot.
I had disabled it in the GUI and used chkconfig --del,--off for jexec.

I have not bothered to check if jexec is running after a boot.
I have a script to automagically put the exit in so I never have
to worry about it running or even checked to see if the /feature/ is
still active.

> I'll post back if/when I figure out what's doing it. May take a few days.

I was guessing since it happened only on boot, it was some other part
of the rpm which started jexec running.
I glanced in the tar awhile back, and it does not ship with init.d/jexec.

On Wed, 13 Aug 2008 19:42:46 -0400, David W. Hodgins wrote:

> I'll post back if/when I figure out what's doing it. May take a few days.

I removed my exit 0 from jexec, made sure On Boot was unchecked, rebooted,
and MCC shows it not running. The /feature/ seems to have been corrected.

Sorry to have wasted everyone's time.

On Wed, 13 Aug 2008 20:43:54 -0400, Bit Twister wrote:

> I removed my exit 0 from jexec, made sure On Boot was unchecked, rebooted,
> and MCC shows it not running. The /feature/ seems to have been corrected.
> Sorry to have wasted everyone's time.

I don't think it is a waste of time. I'm pretty sure I had it disabled, yet it
was back on when I checked a little while ago. This isn't the first time this
has happened with jexec. /etc/init.d/jexec on my system is part of the rpm
jdk-1.6.0_07-fcs from sun, which I installed on 2008-07-19. I'm pretty sure I
turned off jexec after installing, yet something somewhere is somehow turning it
back on. It doesn't appear to be anything in /usr/lib/libDrakx.

I'll check my logs periodically, to see when it's getting turned on. Eventually
I'll figure out how it's happening (assuming it still is).

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Wed, 13 Aug 2008 21:01:28 -0400, David W. Hodgins wrote:
> On Wed, 13 Aug 2008 20:43:54 -0400, Bit Twister wrote:
>
>> I removed my exit 0 from jexec, made sure On Boot was unchecked, rebooted,
>> and MCC shows it not running. The /feature/ seems to have been corrected.
>> Sorry to have wasted everyone's time.
>
> I don't think it is a waste of time. I'm pretty sure I had it
> disabled, yet it was back on when I checked a little while ago.
> This isn't the first time this has happened with jexec.

Well, glad to know it had not happened to just me.

> /etc/init.d/jexec on my system is part of the rpm jdk-1.6.0_07-fcs
> from sun,

My 2008.1 32 bit install is running the jre-6u7-linux-i586-rpm.bin install
from http://java.sun.com/javase/downloads/index.jsp

On Wed, 13 Aug 2008 21:23:06 -0400, Bit Twister wrote:

> Well, glad to know it had not happened to just me.

Aug 14 04:01:02 hodgins cron.hourly: jexec 0ff 1ff 2ff 3ff 4ff 5ff 6ff
Aug 14 05:01:05 hodgins cron.hourly: jexec 0n 1n 2n 3n 4n 5n 6n

It got turned back on during cron.daily. Looks like more digging through msec.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Wed, 13 Aug 2008 21:23:06 -0400, Bit Twister wrote:

> Well, glad to know it had not happened to just me.

Found it. When msec runs from cron.daily, it runs "/usr/lib/rpm/rpmv -V".

Looking at /usr/lib/rpm/rpmv --help, one of the options has ...
Verify options (with -V or --verify):
--noscript don't execute verify script(s)

I didn't know that an rpm package could have a verify script. Looks like the
easiest way to disable jexec, is indeed to edit the startup script, and add
an exit at the front, since not only does the "chkconfig --add" get run, but
also "jexec start".

Looking at the output from "rpm -q --scripts jdk", I find ...

verify scriptlet:

if [ -x /etc/init.d/jexec ]; then
#
# Try to register the init script to the various run levels. If
# possible this is accomplished using an LSB defined install tool.
# If that isn't available, then try to use chkconfig, which is
# supported by Red Hat and Debian. The feature of automatic jar
# file execution is not support on systems which don't support
# either of these interfaces.
#
if [ -x /usr/lib/lsb/install_initd ]; then
/usr/lib/lsb/install_initd jexec > /dev/null 2>&1

# start the service for the current session
/etc/init.d/jexec start > /dev/null 2>&1
elif [ -x /sbin/chkconfig ]; then
/sbin/chkconfig --add jexec > /dev/null 2>&1

# start the service for the current session
/etc/init.d/jexec start > /dev/null 2>&1
fi
fi

The combination of Sun starting the service from the verify scriptlet, and
msec running the rpmv -V, means jexec cannot be disabled.

Should this be considered a bug? It is working, as intended. One way to
stop this, would be to get Mandriva to add the --noscript option to rpmv.
I'm not sure if that is appropriate or not.

Opinions?

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Thu, 14 Aug 2008 15:33:45 -0400, David W. Hodgins wrote:
>
> The combination of Sun starting the service from the verify scriptlet, and
> msec running the rpmv -V, means jexec cannot be disabled.
>
> Should this be considered a bug? It is working, as intended.

I say it is a bug. With my selfish hat on:
I disable it, it should stay disabled.

> One way to
> stop this, would be to get Mandriva to add the --noscript option to rpmv.
> I'm not sure if that is appropriate or not.
>
> Opinions?

Another point for bug, As a security feature, I thought Mandriva went
through and fixed it so daemon/service would not start as part of an
package install. I not sure about that /feature/ though.
Could be, some package manager decided to just not set On Boot in the
packages I happened to noticed used to be On as default.


I am not sure it should be a Mandriva bug though. With the admin hat on:
Sun should have the bug.
Usually you would configure a daemon, then start it.
Not have it running while you get around to configuring it.

With newbie hat on:
I installed the package, it aught to automagically be enabled and
complain if I did not configure something.

Typing this reply, thought comes to mind about some malware turns off
the firewall. It would be nice if the firewall came back on.

How about sshd, on a remote box. Should it come back on, on boot if
disabled. How about that 2008.0 haldaemon/messagebuss update turning
off On Boot and hanging everyone's boot.


I see Sun's point/direction. Java is getting more cross platform, more system
scripts become the norm, jexec needs to be on.

I am starting to feel like a windows user. So many new services are showing
up on each release and I cannot tell if I do not need them or not.

Guessing you will have to let Mandriva decide. I do not know where
the Daemon/Service start/nostart Standard document is. 8-)

On Thu, 14 Aug 2008 17:20:49 -0400, Bit Twister wrote:

> I say it is a bug. With my selfish hat on:
> I disable it, it should stay disabled.

I've thought about it, and decided not to file a bug report for this. While
it was very annoying, not knowing how the service was being restarted/turned on,
now that I know how it's happening, it's less of a worry. Everything is working,
as it was designed to. I don't like having things turned on without my knowledge,
but, accept, that that's become expected by new users.

I considered turning off the rpmcheck, in draksec, but ended up deciding to create ...
# cat /etc/cron.daily/msec.jexec
#!/bin/bash
chkconfig --level 0123456 jexec off
service jexec stop

to undo the change, after msec runs.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"David W. Hodgins" writes:

>On Wed, 13 Aug 2008 21:23:06 -0400, Bit Twister wrote:

>> Well, glad to know it had not happened to just me.

>Aug 14 04:01:02 hodgins cron.hourly: jexec 0ff 1ff 2ff 3ff 4ff 5ff 6ff
>Aug 14 05:01:05 hodgins cron.hourly: jexec 0n 1n 2n 3n 4n 5n 6n

>It got turned back on during cron.daily. Looks like more digging through msec.


The person in Mandriva doing msec is an idiot. He believes that his job is
to be a tyrant and force everyone to do things his way.
Another example. If you set up the cad line in /etc/inittab to shut down
the machine rather than to reboot it, thre is a line in
/usr/share/msec/libmsec.py which turns it to reboot again every night. msec
has absolutely no business messing with things that the sysadmin changed.
But no, that petty tyrant does not believe in such. His approach is best.
I have had a bug report on this in for over 2 years, and they refuse to
change it.

On 2008-08-14, David W. Hodgins wrote:
> On Wed, 13 Aug 2008 21:23:06 -0400, Bit Twister wrote:
>
>> Well, glad to know it had not happened to just me.
>
> Found it. When msec runs from cron.daily, it runs "/usr/lib/rpm/rpmv -V".
>
> Looking at /usr/lib/rpm/rpmv --help, one of the options has ...
> Verify options (with -V or --verify):
> --noscript don't execute verify script(s)
>
> I didn't know that an rpm package could have a verify script. Looks like the
> easiest way to disable jexec, is indeed to edit the startup script, and add
> an exit at the front, since not only does the "chkconfig --add" get run, but
> also "jexec start".
>
> Looking at the output from "rpm -q --scripts jdk", I find ...
>
> verify scriptlet:
>
> if [ -x /etc/init.d/jexec ]; then
> #
> # Try to register the init script to the various run levels. If
> # possible this is accomplished using an LSB defined install tool.
> # If that isn't available, then try to use chkconfig, which is
> # supported by Red Hat and Debian. The feature of automatic jar
> # file execution is not support on systems which don't support
> # either of these interfaces.
> #
> if [ -x /usr/lib/lsb/install_initd ]; then
> /usr/lib/lsb/install_initd jexec > /dev/null 2>&1
>
> # start the service for the current session
> /etc/init.d/jexec start > /dev/null 2>&1
> elif [ -x /sbin/chkconfig ]; then
> /sbin/chkconfig --add jexec > /dev/null 2>&1
>
> # start the service for the current session
> /etc/init.d/jexec start > /dev/null 2>&1
> fi
> fi
>
> The combination of Sun starting the service from the verify scriptlet, and
> msec running the rpmv -V, means jexec cannot be disabled.
>
> Should this be considered a bug? It is working, as intended. One way to
> stop this, would be to get Mandriva to add the --noscript option to rpmv.
> I'm not sure if that is appropriate or not.
>
> Opinions?

I already filed both issues as bug reports. Sun has
acknowledged one of them as a bug. I don't seem to have the
URL at hand.

The init script can be edited to make it default to off at
runlevels 0, 1, and 6. Somebody was completely asleep at
the wheel to have let that bug out!

The only workaround for the problem of "rpm -V java"
enabling the chkconfig state was to uninstall the Java RPM
and reinstall Java with_OUT_ an RPM. That's also a very
serious bug!

HTH

--
Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)

Bit Twister writes:

>On Thu, 14 Aug 2008 15:33:45 -0400, David W. Hodgins wrote:
>>
>> The combination of Sun starting the service from the verify scriptlet, and
>> msec running the rpmv -V, means jexec cannot be disabled.
>>
>> Should this be considered a bug? It is working, as intended.

>I say it is a bug. With my selfish hat on:
>I disable it, it should stay disabled.

It IS a bug. If the sysadmin does something to a machine, that should stay
done. Yes, it may not be the right thing to do, but damn it is my machine,
not Mandriva's I do not mind them starting up the scripts on installation,
but there they at least ask you if you want to change things. To change
things without notificatio of verification IS a bug.



>> One way to
>> stop this, would be to get Mandriva to add the --noscript option to rpmv.
>> I'm not sure if that is appropriate or not.
>>
>> Opinions?

>Another point for bug, As a security feature, I thought Mandriva went
>through and fixed it so daemon/service would not start as part of an
>package install. I not sure about that /feature/ though.
>Could be, some package manager decided to just not set On Boot in the
>packages I happened to noticed used to be On as default.


>I am not sure it should be a Mandriva bug though. With the admin hat on:
>Sun should have the bug.
>Usually you would configure a daemon, then start it.
>Not have it running while you get around to configuring it.

Nuts. You configure a daemon and then you decide to run it or not. There
are about 10000 programs on my system. Should all of them be started at
bootup, "since they have been installed they should be running, otherwise
why were they installed?"



>With newbie hat on:
>I installed the package, it aught to automagically be enabled and
>complain if I did not configure something.

No it should not. It might ask you if you want to start it, it should not
do it on its own.


>Typing this reply, thought comes to mind about some malware turns off
>the firewall. It would be nice if the firewall came back on.

No. That firewall should perhaps shout a warning if it is off, but it is up
the user to decide.


>How about sshd, on a remote box. Should it come back on, on boot if
>disabled. How about that 2008.0 haldaemon/messagebuss update turning
>off On Boot and hanging everyone's boot.

No. If sshd is not configured in /etc/rc{3,5}.d it should not come on on its own.


>I see Sun's point/direction. Java is getting more cross platform, more system
>scripts become the norm, jexec needs to be on.

No it does not.


>I am starting to feel like a windows user. So many new services are showing
>up on each release and I cannot tell if I do not need them or not.

>Guessing you will have to let Mandriva decide. I do not know where
>the Daemon/Service start/nostart Standard document is. 8-)

No. Mandriva should not decide. They can send up warning messages. They
should not be changing what a sysadmin has set up. That is why I always run
at runlevel 2. Much less of this idiotic nannying.

Unruh wrote:

> Bit Twister writes:
>
>>On Thu, 14 Aug 2008 15:33:45 -0400, David W. Hodgins wrote:
>>>
>>> The combination of Sun starting the service from the verify scriptlet,
>>> and msec running the rpmv -V, means jexec cannot be disabled.
>>>
>>> Should this be considered a bug? It is working, as intended.
>
>>I say it is a bug. With my selfish hat on:
>>I disable it, it should stay disabled.
>
> It IS a bug. If the sysadmin does something to a machine, that should
> stay done. Yes, it may not be the right thing to do, but damn it is my
> machine, not Mandriva's I do not mind them starting up the scripts on
> installation, but there they at least ask you if you want to change
> things. To change things without notificatio of verification IS a bug.

That's why the first thing I do after installing or upgrading Mandriva is
to uninstall msec.
--
Dave

On Thu, 14 Aug 2008 23:18:55 -0400, Robert Riches wrote:

> I already filed both issues as bug reports. Sun has
> acknowledged one of them as a bug. I don't seem to have the
> URL at hand.

Found the sun bug report at
http://bugs.sun.com/view_bug.do?bug_id=6620027

I don't see a bug report for this at qa.mandriva.com

I think I'll put something together to see which other rpm packages
include verify scriptlets. If I don't find any that really should be
run, I think I will file a bug report for msec, reqeusting the addition
of the --noscripts option to the rpm -V command.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)