ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "Alan Hourihane" <al...@fa...>
To: <ipc...@li...>
Sent: Monday, June 30, 2008 11:47 PM
Subject: Re: [IPCop-devel] [IPCop-cvs] ipcop/updates/1.4.19
information,1.1.2.13, 1.1.2.14 setup, 1.1.2.10, 1.1.2.11


...
> > + /bin/rm -f usr/lib/libiw.so.27
>
> Mmmm. usr/lib/libiw.so.27 sounds like a library from the wireless tools.
> Are you sure those haven't blown up ?
>
> ldd /sbin/iwconfig ??
>
> The kernel won't be using this library I'm sure.
>
> Alan.
>
Right, kernel don't use the lib.
wireless_tools.27 and corresponding patch were used with kernel 2.4.31
Since kernel 2.6.34, wireless_tools.28 is supplied.

Inside make.sh shell
ldd usr/sbin/iwconfig
        /lib/libsafe.so.2 => /lib/libsafe.so.2 (0xb7f43000)
        linux-gate.so.1 =>  (0xffffe000)
        libiw.so.28 => /usr/lib/libiw.so.28 (0xb7f39000)
        libm.so.6 => /lib/libm.so.6 (0xb7f17000)
        libc.so.6 => /lib/libc.so.6 (0xb7ddd000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7dda000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7f4a000)

Gilles

On Mon, 2008-06-30 at 21:30 +0000, Gilles Espinasse wrote:
> Update of /cvsroot/ipcop/ipcop/updates/1.4.19
> In directory sc8-pr-cvs2.sourceforge.net:/tmp/cvs-serv20814/updates/1.4.19
> 
> Modified Files:
>       Tag: IPCOP_v1_4_0
> 	information setup 
> Log Message:
> Upgrade squid to 2.6.STABLE21
> 
> Move squid update from 1.4.20 to 1.4.19
> There is more free space during 1.4.19 installation as 2.4.31 kernel is
> removed, so first update could be the biggest.
> 
> Reorder 1.4.19 setup
> first : suppressed files
> last  : program restarted
> 
> 
> Index: information
> ===================================================================
> RCS file: /cvsroot/ipcop/ipcop/updates/1.4.19/Attic/information,v
> retrieving revision 1.1.2.13
> retrieving revision 1.1.2.14
> diff -C2 -d -r1.1.2.13 -r1.1.2.14
> *** information	22 Jun 2008 20:11:49 -0000	1.1.2.13
> --- information	30 Jun 2008 21:30:46 -0000	1.1.2.14
> ***************
> *** 1 ****
> ! 019|1.4.19 update|Fix system log update filter. Upgrade apache to 1.3.41, bzip2 to 1.0.5, dnsmasq to 2.41, e1000 to 7.6.15.5, openssh to 4.7p1, pcre to 7.6, update tzdata to 2008c <br />The IPCop vendor pool of timeservers is now available. Please use 0.ipcop.pool.ntp.org or 1.ipcop.pool.ntp.org instead of the previous default name of pool.ntp.org<br />linux-2.4.36 upgrade first part.|2008-05-xx
> --- 1 ----
> ! 019|1.4.19 update|Fix system log update filter. Upgrade apache to 1.3.41, bzip2 to 1.0.5, dnsmasq to 2.41, e1000 to 7.6.15.5, openssh to 4.7p1, pcre to 7.6, squid to 2.6STABLE21, tzdata to 2008c <br />The IPCop vendor pool of timeservers is now available. Please use 0.ipcop.pool.ntp.org or 1.ipcop.pool.ntp.org instead of the previous default name of pool.ntp.org<br />linux-2.4.36 upgrade first part. <br /><b>Install 1.4.20 update before to reboot</b>|2008-05-xx
> 
> Index: setup
> ===================================================================
> RCS file: /cvsroot/ipcop/ipcop/updates/1.4.19/Attic/setup,v
> retrieving revision 1.1.2.10
> retrieving revision 1.1.2.11
> diff -C2 -d -r1.1.2.10 -r1.1.2.11
> *** setup	23 Jun 2008 17:09:05 -0000	1.1.2.10
> --- setup	30 Jun 2008 21:30:46 -0000	1.1.2.11
> ***************
> *** 17,23 ****
> --- 17,45 ----
>   fi
>   
> + # Suppress the old kernel to make place for a new kernel
> + /bin/rm -rf	/lib/modules/2.4.31{,-smp}	\
> + 		/boot/vmlinuz-2.4.31{,-smp}	\
> + 		/boot/System.map-2.4.31{,-smp}	\
> + 		/boot/ipcoprd-2.4.31.img	\
> + 		/boot/ipcoprd-smp-2.4.31.img
> + # was only used with 2.4.31
> + /bin/rm -f usr/lib/libiw.so.27

Mmmm. usr/lib/libiw.so.27 sounds like a library from the wireless tools.
Are you sure those haven't blown up ?

ldd /sbin/iwconfig ??

The kernel won't be using this library I'm sure.

Alan.

Gilles Espinasse wrote:

> I have tested too and noted a few problems
> My test has been to install 1.4.11 and apply all updates until 1.4.19 and
> reboot (with intermediate reboot after 1.4.13)
> With IDE 6.4GB disk size and IDE 273MB disk size, it's fine.
> On small disk, I have selected UP kernel on 1.4.17.

I tried similar over the weekend (installed 1.4.9 and updated up till 
1.4.18) on IDE with 256 MB and 128 MB RAM. I had one surprise because 
after deleting SMP kernel and reboot, I was left with 2.4.31 kernel.
Cause is that I choose ACPI kernel before, which is #3 in grub.conf 
normally. If SMP is removed the number 3 position becomes old kernel 
with ACPI disabled.

Not nice, but can't be (easily) helped.


> I had no problems rebooting after 1.4.19 update but to my surprise 2.4.36
> kernel was used.
> Explanation for the 'no problems' is because I don't use the few 2.4.36 adsl
> modules include in 1.4.20 (and not in 1.4.19).

In my case 2.4.34 was booted. System.map and vmlinuz still symlink to 
2.4.34, the 2.4.36 versions are there, but unused.
Simply because there is no grub.conf modification done (yet) in 1.4.20/setup


> What is curious is that after 1.4.19 update actually ipcoprd.img include
> 2.4.34 modules and it boot with 2.4.36 vmlinuz. That look to work.

I will check again (redo install+update), but I am pretty sure the box 
is all 2.4.34 after update.



I think we need to concentrate a little on 1.4.19/1.4.20 now and 
finalize the update.
For me there are no open issues, apart from removing 2.4.31 kernel and 
modifying grub in setup.



Olaf

-- 

A weizen a day helps keep the doctor away.

Feature Requests item #2006678, was opened at 2008-06-30 06:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=2006678&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Ricardo Gimenez (ricardogimenez)
Assigned to: Nobody/Anonymous (nobody)
Summary: SATA RAID

Initial Comment:
I need to install the Ipcop on HP DL320 G5 System using raid intel ICH9R. I have tried almost 20 times and the same trouble was returning = " No Hardisk Foubded "
I read on the latest posts that I need to include the raid intarface module inside the Ipcop Module . But I do not know to do that . Some one could help me ?

Thanks 

Ricardo Gimenbez

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=2006678&group_id=40604

> Revision: 1537
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1537&view=rev
> Author:   owes
> Date:     2008-06-29 01:06:57 -0700 (Sun, 29 Jun 2008)
> 
> Log Message:
> -----------
> Someone remembers why logfile pages are *.dat in logs.cgi?
> Probably time to change that into logs/*.cgi

I think that has something to do with the export function. When you save the
exported data with your browser, the browser will use the filename (e.g. *.dat)
as presetting. When you later open your exported file, the .dat extension is
probably better than the .cgi extension.

Achim

Hello list,


whilst looking at the GUI pages I noticed that connections.cgi is 
currently broke (change in format of entry lines in /proc/net/ip_conntrack).

This just might be a good time to include conntrack-tools 
http://conntrack-tools.netfilter.org/index.html together with companion 
  libnfnetlink and libnetfilter_conntrack

Anyone used conntrack-tools?  Pros?  Cons?


Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:
> Gilles Espinasse wrote:
> 
>> It may be happen bad thing writing to /proc/sys/vm/vdso_enabled
>> On my 2.6.25 kernel with CONFIG_COMPAT_VDSO=y, vdso_enabled is normally at
>> 2.
> 
> I have not tested this (my main machines all run 2.6.18-something), but 
> would it not be better stop make.sh with a message about VDSO before to 
> start changing /proc/sys/vm/vdso_enabled ?
> 
> Test on vdso_enabled = 1 and kernel with possible problem, if yes stop 
> make.sh and output message containing what should be done.
> 
> To me this sound better than changing vdso_enabled and possibly leave 
> the system in unstable situation.
> 
> 
> Olaf
> 
> 

I agree - I don't think it's a good idea for the build script to make
what could appear to be arbitrary changes to the host system.
It would be much better to test for this case, and then inform the user
of the issue and what they need to do to work around it, along with what
the ramifications are.

Chris

Gilles Espinasse wrote:

> It may be happen bad thing writing to /proc/sys/vm/vdso_enabled
> On my 2.6.25 kernel with CONFIG_COMPAT_VDSO=y, vdso_enabled is normally at
> 2.

I have not tested this (my main machines all run 2.6.18-something), but 
would it not be better stop make.sh with a message about VDSO before to 
start changing /proc/sys/vm/vdso_enabled ?

Test on vdso_enabled = 1 and kernel with possible problem, if yes stop 
make.sh and output message containing what should be done.

To me this sound better than changing vdso_enabled and possibly leave 
the system in unstable situation.


Olaf


-- 

A weizen a day helps keep the doctor away.

Selon Achim Weber <dot...@gm...>:

> > Don't you have vdo=0 on grub boot line for that kernel?
> > But in that case, you should have vdso_enabled=0.
>
> Ups, I did recheck my config, I have "CONFIG_COMPAT_VDSO=y" in my custom
> kernel too (not sure what I checked last time). But shouldn't I have '2' in
> /proc/sys/vm/vdso_enabled than? In my boot line is nothing about vdso.
>
> Sorry for the confusion!
>
> Achim
>
> PS:
> I think you should commit your patch, it doesn't seam to hurt.
>
vdso=2 has been added at a date wich should match 2.6.22 kernel
thank to the search box on linus git tree.

http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=VDSO

That mean make.sh patch may unnecessary disable vdso with kernel from 2.6.18 to
2.6.21 as we can't rely on vdso_enabled value to know if CONFIG_COMPAT_VDSO is
set or not.
I don't know much of vdso, maybe this page
http://www.trilithium.com/johan/2005/08/linux-gate/
I suppose disabling vdso is a speed penality.

Another approach would be to try to use glibc-2.3.3 (enter stage2 shell for
example) and if it fail disable vdso.
Look too much complicated for me actually as I need to handle too toolchain
compilation case.

This was started as a simple fix for everyone.


Gilles

> Don't you have vdo=0 on grub boot line for that kernel?
> But in that case, you should have vdso_enabled=0.

Ups, I did recheck my config, I have "CONFIG_COMPAT_VDSO=y" in my custom kernel
too (not sure what I checked last time). But shouldn't I have '2' in
/proc/sys/vm/vdso_enabled than? In my boot line is nothing about vdso.

Sorry for the confusion!

Achim

PS:
I think you should commit your patch, it doesn't seam to hurt.

Selon Achim Weber <dot...@gm...>:

> Hi Gilles
>
> > The trick to set to 0 to compile ipcop-1.4 work on Ubuntu 2.6.24 with
> > "CONFIG_COMPAT_VDSO not set"
>
> So this fix is needed for Ubuntu only?
>
No, this is not at all Ubuntu specific.

> I did two full builds (toolchain removed + clean), the first was with current
> CVS make.sh, the second was with your patched make.sh. Both build were fine,
> ISO installs and IPCop boots up. BTW I noticed the toolchain increased by 3MB
> in size since november.
>

> System is Debian Etch with custom kernel 2.6.21.7 ("CONFIG_COMPAT_VDSO not
> set").
>
> As far as I understand, there is a problem when using a new(er) kernel (e.g.
> 2.6.18) and an old glibc (< 2.3.3). From [1] I read, it is recommented to
> turn the option off (what I did in my kernel) for security reasons.
> I think Ubuntu uses more recent packages than Etch, so I don't understand why
I have no
> issue
> to build with VDSO=1 but Ubuntu has issues?
>
Don't you have vdo=0 on grub boot line for that kernel?
But in that case, you should have vdso_enabled=0.

vdso hit me first on 2.6.20 kernel on my gentoo machine with custom kernel but I
irregulary play with new kernels.
>
> Achim
>
> PS: On another Etch machine with original Etch kernel 2.6.18 the option is
> enabled ("CONFIG_COMPAT_VDSO=y") but in /proc/sys/vm/vdso_enabled is a '1'.
> Now I'm completely confused.
> Is this option added to 2.6.18 but used in later kernels only?
>
This option was added to 2.6.18
It has been fixed in 2.6.20.2.
> [1]
>
http://kernelnewbies.org/Linux_2_6_18#head-d436870fd6bb7290add540e62b52641196dbe179
>
What is unclear for me is that we have glibc-2.3.3 so randomized vdso should be
supported.
Maybe this is because glibc-2.3.3-LFS is a snapshot and not released version?


Gilles

Hi Gilles

> The trick to set to 0 to compile ipcop-1.4 work on Ubuntu 2.6.24 with
> "CONFIG_COMPAT_VDSO not set"

So this fix is needed for Ubuntu only?

I did two full builds (toolchain removed + clean), the first was with current
CVS make.sh, the second was with your patched make.sh. Both build were fine, ISO
installs and IPCop boots up. BTW I noticed the toolchain increased by 3MB in
size since november.

System is Debian Etch with custom kernel 2.6.21.7 ("CONFIG_COMPAT_VDSO not set").

As far as I understand, there is a problem when using a new(er) kernel (e.g. >
2.6.18) and an old glibc (< 2.3.3). From [1] I read, it is recommented to turn
the option off (what I did in my kernel) for security reasons. I think Ubuntu
uses more recent packages than Etch, so I don't understand why I have no issue
to build with VDSO=1 but Ubuntu has issues?


Achim

PS: On another Etch machine with original Etch kernel 2.6.18 the option is
enabled ("CONFIG_COMPAT_VDSO=y") but in /proc/sys/vm/vdso_enabled is a '1'. Now
I'm completely confused. Is this option added to 2.6.18 but used in later
kernels only?

[1]
http://kernelnewbies.org/Linux_2_6_18#head-d436870fd6bb7290add540e62b52641196dbe179

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Tuesday, June 24, 2008 9:15 PM
Subject: Re: [IPCop-devel] Include vdso fix in make.sh?


> Hi Gilles
>
> I'm using a custom kernel 2.6.21.x with "CONFIG_COMPAT_VDSO not set", so I
have
> the 1 in the vdso_enabled file.
>
> Is it possible I run into trouble (system crash etc.) if the flag is set
from 1
> to 0? Or is the 1 only something like "unknown" state and handled like
> "disabled" (value 0)?
>
> Achim
>
COMPAT_VDSO is vdso_enabled=2
enum {
 VDSO_DISABLED = 0,
 VDSO_ENABLED = 1,
 VDSO_COMPAT = 2,
};

CONFIG_COMPAT_VDSO has been added on 2.6.18
Before 2.6.18 vdso was at a fixed address
Starting from 2.6.18, start address was randomized, a reason to add
CONFIG_COMPAT_VDSO  to make new kernels still work with old glibc.
google is my friend
http://www.linuxinsight.com/proc_sys_vm_vdso_enabled.html

Before 2.6.18, randomized vdso was an exec-shield patch.

You could disable vdso without CONFIG_COMPAT_VDSO set.
The trick to set to 0 to compile ipcop-1.4 work on Ubuntu 2.6.24 with
"CONFIG_COMPAT_VDSO not set"

I think the only problem is with CONFIG_COMPAT_VDSO set, so vdso_enabled=2
unless you use vdso=0 on boot line. If you write a '1' start address is
randomised and segfault happen.
The script prevent that.

I have attached a gziped make.sh with the patch, that's easier than
patching.

Gilles

Hi Gilles

I'm using a custom kernel 2.6.21.x with "CONFIG_COMPAT_VDSO not set", so I have
the 1 in the vdso_enabled file.

Is it possible I run into trouble (system crash etc.) if the flag is set from 1
to 0? Or is the 1 only something like "unknown" state and handled like
"disabled" (value 0)?

Achim



> I have written this patch to current cvs make.sh (so for 1.4)
> 
> When vdso_enabled=1, it write a 0 to let us use glibc-2.3 and restore 1
> value on exit.
> 
> Actually this is in 'work for me' state, tested on
> - debian etch kernel 2.6.18 (is not needed, but does not break)
> - ubuntu 8.04 kernel 2.6.24 (is needed)
> - my customized gentoo with vanilia 2.6.25.x kernel with
> CONFIG_COMPAT_VDSO=y, so not needed
> 
> It may be happen bad thing writing to /proc/sys/vm/vdso_enabled
> On my 2.6.25 kernel with CONFIG_COMPAT_VDSO=y, vdso_enabled is normally at
> 2.
> 
> On this 2.6.25 kernel with vdso_enabled=2, writing 1 there is a sure way to
> segfault with everything and to need to reboot from hardware switch.
> Script prevent that but I would have opinion from other and test feedback
> before to commit.
> 
> Gilles
> 
> 

On Tue, Jun 24, 2008 at 11:44 AM, Gilles Espinasse <g....@fr...> wrote:
> I have written this patch to current cvs make.sh (so for 1.4)
>
> When vdso_enabled=1, it write a 0 to let us use glibc-2.3 and restore 1
> value on exit.
>
> Actually this is in 'work for me' state, tested on
> - debian etch kernel 2.6.18 (is not needed, but does not break)
> - ubuntu 8.04 kernel 2.6.24 (is needed)
> - my customized gentoo with vanilia 2.6.25.x kernel with
> CONFIG_COMPAT_VDSO=y, so not needed
>
> It may be happen bad thing writing to /proc/sys/vm/vdso_enabled
> On my 2.6.25 kernel with CONFIG_COMPAT_VDSO=y, vdso_enabled is normally at
> 2.
>
> On this 2.6.25 kernel with vdso_enabled=2, writing 1 there is a sure way to
> segfault with everything and to need to reboot from hardware switch.
> Script prevent that but I would have opinion from other and test feedback
> before to commit.
>
> Gilles

Works for me Gilles

Eric

john s wolter wrote:
> Harry,
> 
> Ok, that was easy.  I just had to string the KVM cables in the data
> center, start, run down the hall to the keyboard, hit DEL just in time,
> adjust the BIOS, shutdown, disconnect the KVM cables, start, and then
> restart the network hosts as needed.  The LINUX machines reconnected to
> the network themselves, some MS hosts needed a restart for some unknown
> reason.
> 
> Does anyone have opinions on a REALLY cheap remote console over TCP/IP box?
> 

John,

We use a lot of OpenGears where I work now.. They definitely do 8-port
and 48-port models. Not sure if there's anything in between, but they do
excellent serial-based admin.
If you need an IP-KVM though, you're probably looking at
insane-quantities of money.. Better to have a monitor & kb in the data
centre in one of the racks. Oh, and remotely managed power is a godsend ;)


As for the M$ boxes - an ipconfig /release; ipconfig /renew would
probably have sorted them, but windows does have something of a mind of
its own.


Chris

> On Mon, Jun 23, 2008 at 2:28 PM, Harry Goldschmitt <ha...@hg...
> <mailto:ha...@hg...>> wrote:
> 
>     At 10:38 AM -0400 6/23/08, john s wolter wrote:
> 
>         I spotted that the GUI Time Server display shows a time that is
>         1 hour [less] different from the date command from the terminal.
>          I suspect that may have to do with the daylight savings time
>         setting. The systemboard BIOS setting is set to account for
>         daylight savings time and shows that corrected time when viewed.
>          What could I look at to have the GUI Time Server display
>         correspond to the date command?
> 
> 
>     First turn off the daylight savings time in the BIOS.  IPCop and the
>     BIOS are both compensating for it.  Second set up IPCop with the
>     correct time zone, using  the setup command from root.  IPCop will
>     keep the hardware clock at UTC (GMT) and use its internal
>     inforamtion to adjust the time.
> 
>     Harry
> 
> 
> 
> 
> -- 
> John S. Wolter President
> Wolter Works
> Mailto:joh...@wo... <mailto:joh...@wo...>
> Desk 1-734-665-1263
> Cell: 1-734-904-8433
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

I have written this patch to current cvs make.sh (so for 1.4)

When vdso_enabled=1, it write a 0 to let us use glibc-2.3 and restore 1
value on exit.

Actually this is in 'work for me' state, tested on
- debian etch kernel 2.6.18 (is not needed, but does not break)
- ubuntu 8.04 kernel 2.6.24 (is needed)
- my customized gentoo with vanilia 2.6.25.x kernel with
CONFIG_COMPAT_VDSO=y, so not needed

It may be happen bad thing writing to /proc/sys/vm/vdso_enabled
On my 2.6.25 kernel with CONFIG_COMPAT_VDSO=y, vdso_enabled is normally at
2.

On this 2.6.25 kernel with vdso_enabled=2, writing 1 there is a sure way to
segfault with everything and to need to reboot from hardware switch.
Script prevent that but I would have opinion from other and test feedback
before to commit.

Gilles

Maybe all this thread is a big misunderstanding?

Info from http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopSupport
################################################################
#                                                              #
# ===> IPCop Mailing Lists ===                                 #
# IPCop-Announce (Low Traffic)                                 #
# IPCop-User                                                   #
# IPCop-Devel                                                  #
# IPCop-CVS                                                    #
# IPCop-SVN                                                    # 
#                                                              #
# ===> Community and Support Websites (forums) ===             #
# http://www.ipcops.com/ (English)                             #
# Total posts 60767 | Total topics 11068 | Total members 5869  #
#                                                              #
# And also                                                     #
# http://forum.softgil.com/ (English)                          #
# http://www.ipcop-forum.de/ (German)                          #
# http://www.ixus.net/ (French)                                #
# http://ipcop.forumcommunity.net/ (Italian)                   #
# http://ipcop.elektroda.eu/ (Polish)                          #
# http://www.security.ly/ipcop/ (Arabic)                       #
#                                                              # 
################################################################

So we have several mailing lists and several discussion forums. This
should be enough for every opinion in this thread? If you like mailing
lists > use them. If you like forums > use them. If you ask someone to
change his ways, and this someone don't want to? Respect each others
point of view, you cant force your conviction on someone else, just move
on to the information way you like... And if YOU need to communicate
with PERSON X who likes mailing lists or web based forums, do it the way
PERSON X likes. Education is the ability to listen to almost anything
without losing your temper or your self-confidence (Robert Frost). I can
win an argument on any topic, against any opponent. People know this,
and steer clear of me at parties. Often, as a sign of their great
respect, they don't even invite me (Dave Barry). Sorry, I found this
Quotation site, and find it funny to insert quotes wherever they are
inappropriate...
        \\\//
        (0 0)
----oOO--(_)--OOo-----

That was completely simple.  It worked immediately.  Why isn't this the
default configuration?

On Mon, Jun 23, 2008 at 5:43 PM, HPDrifter <hpd...@gm...> wrote:

> Have a look here: http://marc.info/?l=ipcop-user&m=114632125708156&w=2
>
> Greg
>
> ----- Original Message ----- From: "john s wolter" <
> joh...@wo...>
> To: <ipc...@li...>; "john s wolter" <
> joh...@wo...>
> Sent: Monday, June 23, 2008 3:30 PM
> Subject: [mail-list] [IPCop-devel] My GUI is showing when accessing my
> IPCOP machine viathe Internet.
>
>
>
>  The IPCOP GUI web page is displayed when I go its URL and access port
>> number
>> prior to doing a sign-on.  I was wondering if there is a way to turn off
>> that page until after a valid sign-on is completed or to substitute a
>> mostly
>> blank page.  When a valid sign-on is completed the normal IPCOP page would
>> then be displayed.
>>
>> I know that security-through-obscurity does not work.  I was reasoning
>> that
>> page gives an attacker an idea of what firewall is installed.  A blank
>> page
>> with a simple sign-on error page would be of some some security value.
>>
>> --
>> John S. Wolter President
>> Wolter Works
>> Mailto:joh...@wo...
>> Desk 1-734-665-1263
>> Cell: 1-734-904-8433
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>  -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>>
>
>
>
> --------------------------------------------------------------------------------
>
>
>  _______________________________________________
>> IPCop-devel mailing list
>> IPC...@li...
>> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>>
>>
>
>


-- 
John S. Wolter President
Wolter Works
Mailto:joh...@wo...
Desk 1-734-665-1263
Cell: 1-734-904-8433

Have a look here: http://marc.info/?l=ipcop-user&m=114632125708156&w=2

Greg

----- Original Message ----- 
From: "john s wolter" <joh...@wo...>
To: <ipc...@li...>; "john s wolter" 
<joh...@wo...>
Sent: Monday, June 23, 2008 3:30 PM
Subject: [mail-list] [IPCop-devel] My GUI is showing when accessing my IPCOP 
machine viathe Internet.


> The IPCOP GUI web page is displayed when I go its URL and access port 
> number
> prior to doing a sign-on.  I was wondering if there is a way to turn off
> that page until after a valid sign-on is completed or to substitute a 
> mostly
> blank page.  When a valid sign-on is completed the normal IPCOP page would
> then be displayed.
>
> I know that security-through-obscurity does not work.  I was reasoning 
> that
> page gives an attacker an idea of what firewall is installed.  A blank 
> page
> with a simple sign-on error page would be of some some security value.
>
> -- 
> John S. Wolter President
> Wolter Works
> Mailto:joh...@wo...
> Desk 1-734-665-1263
> Cell: 1-734-904-8433
>


--------------------------------------------------------------------------------


> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php


--------------------------------------------------------------------------------


> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> 

The IPCOP GUI web page is displayed when I go its URL and access port number
prior to doing a sign-on.  I was wondering if there is a way to turn off
that page until after a valid sign-on is completed or to substitute a mostly
blank page.  When a valid sign-on is completed the normal IPCOP page would
then be displayed.

I know that security-through-obscurity does not work.  I was reasoning that
page gives an attacker an idea of what firewall is installed.  A blank page
with a simple sign-on error page would be of some some security value.

-- 
John S. Wolter President
Wolter Works
Mailto:joh...@wo...
Desk 1-734-665-1263
Cell: 1-734-904-8433

Harry,

Ok, that was easy.  I just had to string the KVM cables in the data center,
start, run down the hall to the keyboard, hit DEL just in time, adjust the
BIOS, shutdown, disconnect the KVM cables, start, and then restart the
network hosts as needed.  The LINUX machines reconnected to the network
themselves, some MS hosts needed a restart for some unknown reason.

Does anyone have opinions on a REALLY cheap remote console over TCP/IP box?

On Mon, Jun 23, 2008 at 2:28 PM, Harry Goldschmitt <ha...@hg...> wrote:

> At 10:38 AM -0400 6/23/08, john s wolter wrote:
>
>> I spotted that the GUI Time Server display shows a time that is 1 hour
>> [less] different from the date command from the terminal.  I suspect that
>> may have to do with the daylight savings time setting. The systemboard BIOS
>> setting is set to account for daylight savings time and shows that corrected
>> time when viewed.  What could I look at to have the GUI Time Server display
>> correspond to the date command?
>>
>
> First turn off the daylight savings time in the BIOS.  IPCop and the BIOS
> are both compensating for it.  Second set up IPCop with the correct time
> zone, using  the setup command from root.  IPCop will keep the hardware
> clock at UTC (GMT) and use its internal inforamtion to adjust the time.
>
> Harry
>



-- 
John S. Wolter President
Wolter Works
Mailto:joh...@wo...
Desk 1-734-665-1263
Cell: 1-734-904-8433

At 10:38 AM -0400 6/23/08, john s wolter wrote:
>I spotted that the GUI Time Server display shows a time that is 1 
>hour [less] different from the date command from the terminal.  I 
>suspect that may have to do with the daylight savings time setting. 
>The systemboard BIOS setting is set to account for daylight savings 
>time and shows that corrected time when viewed.  What could I look 
>at to have the GUI Time Server display correspond to the date 
>command?

First turn off the daylight savings time in the BIOS.  IPCop and the 
BIOS are both compensating for it.  Second set up IPCop with the 
correct time zone, using  the setup command from root.  IPCop will 
keep the hardware clock at UTC (GMT) and use its internal inforamtion 
to adjust the time.

Harry

I spotted that the GUI Time Server display shows a time that is 1 hour
[less] different from the date command from the terminal.  I suspect that
may have to do with the daylight savings time setting.  The systemboard BIOS
setting is set to account for daylight savings time and shows that corrected
time when viewed.  What could I look at to have the GUI Time Server display
correspond to the date command?

-- 
John S. Wolter President
Wolter Works
Mailto:joh...@wo...
Desk 1-734-665-1263
Cell: 1-734-904-8433

Andrew Borland wrote:

> David W Studeman wrote:
>> The Gmane server ... Once set up it's very nice
>> to follow threads all the way back.
>>
> 
> Thank you for bring Gmane to my attention.  Whilst it probably isn't
> relevant for IPCop matters (as I have my own list archives going back to
> 2003) it could be of immense value for lists I've joined more recently.
> 
> Long live the mailing list!
> 
> Regards,  Andrew Borland (UK)
> 
> 

No problem at all. I accidentally stumbled on it and realized that most
sourceforge mailing lists as well as things like lcdproc, lcd4linux and
such are also carried. 


Dave