ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #1671315, was opened at 2007-03-01 01:10
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=1671315&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: Noam Segal (nsegal)
Assigned to: Nobody/Anonymous (nobody)
Summary: PPTP dialup support

Initial Comment:
Hi
Is there a plan to add PPTP dial up support (in addition to PPPoE) ?


Thanks,
Noam Segal

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

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

Feature Requests item #1670711, was opened at 2007-02-28 05:28
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=1670711&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: Darkk69 (darkk69)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Option for GUI Access

Initial Comment:
Add option to restrict access to only allow green network to the GUI web admin page.  Red is already restricted so why not add blue and orange to the list? 


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

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

Feature Requests item #1670512, was opened at 2007-02-28 06:48
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=1670512&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: Elecen (elecen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crypto F200 USB Driver

Initial Comment:
Driver for USB Crypto F200 modem. Its based on connexant chip. I've been told that on linux we can install this modem using the AccessRunner (http://sourceforge.net/projects/accessrunner) drivers which is intented for the Alcatel Speedtouch and with some tweaking at the kernel.

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

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

A few new sentences has been added on the langs database.
http://www.ipcop.org/langs/

Could every people quickly work on the new translations so they could be include
on 1.4.14?
I will start build 1.4.14 the 28 Februar 20h (Paris time) for the test release.
This should be available for x86 3 hours later on the mirrors.

I will let only one day for qualification of the release due to the constraint
of US 'daylight changing time'.

For alpha, my machine need one day to build, so no test release will be
proposed, this will be directly the official release.

If someone has password problem to authenticate on the translation database, he
should address to me now.

Gilles

----- Original Message ----- 
From: "Heath Henderson" <he...@a5...>
To: "IPCOP devel" <ipc...@li...>
Sent: Monday, February 26, 2007 11:05 PM
Subject: Re: [IPCop-devel] Dell server SCSI driver


> The driver looks to be a megaraid driver.
>
> I am curious as to why ipcop isn't detecting it?
>
> CONFIG_SCSI_MEGARAID=m
>
>
> The driver I pulled from Dell shows a megaraid driver.  LSI logical is the
> manufacturer.
>
> Was just curious.  Is there a way to specify which driver to use on first
> boot/install
>
no
what are the pci id of the controller
during install, you could go on console3 with ctrl/F3 and type
cat /proc/pci/devices

Gilles

The driver looks to be a megaraid driver.

I am curious as to why ipcop isn't detecting it?

CONFIG_SCSI_MEGARAID=m


The driver I pulled from Dell shows a megaraid driver.  LSI logical is the
manufacturer.

Was just curious.  Is there a way to specify which driver to use on first
boot/install
-- 
Heath Henderson
he...@a5...
--



> From: Gilles Espinasse <g....@fr...>
> Date: Mon, 26 Feb 2007 22:56:12 +0100
> To: Heath Henderson <he...@a5...>
> Cc: IPCOP devel <ipc...@li...>
> Subject: Re: [IPCop-devel] Dell server SCSI driver
> 
> 
> ----- Original Message -----
> From: "Heath Henderson" <he...@a5...>
> To: <ipc...@li...>
> Sent: Monday, February 26, 2007 10:10 PM
> Subject: [IPCop-devel] Dell server SCSI driver
> 
> 
>> Curious if there is a listing out there of the SCSI driver set included
> with
>> the current release?
>> 
> this is drivers available on 2.4 kernel
> # SCSI low-level drivers
> #
> CONFIG_BLK_DEV_3W_XXXX_RAID=m
> CONFIG_SCSI_7000FASST=m
> CONFIG_SCSI_ACARD=m
> CONFIG_SCSI_AHA152X=m
> CONFIG_SCSI_AHA1542=m
> CONFIG_SCSI_AHA1740=m
> CONFIG_SCSI_AACRAID=m
> CONFIG_SCSI_AIC7XXX=m
> CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
> CONFIG_AIC7XXX_RESET_DELAY_MS=15000
> CONFIG_AIC7XXX_PROBE_EISA_VL=y
> # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
> # CONFIG_AIC7XXX_DEBUG_ENABLE is not set
> CONFIG_AIC7XXX_DEBUG_MASK=0
> # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
> CONFIG_SCSI_AIC79XX=m
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=15000
> # CONFIG_AIC79XX_BUILD_FIRMWARE is not set
> CONFIG_AIC79XX_ENABLE_RD_STRM=y
> # CONFIG_AIC79XX_DEBUG_ENABLE is not set
> CONFIG_AIC79XX_DEBUG_MASK=0
> # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
> # CONFIG_SCSI_AIC7XXX_OLD is not set
> CONFIG_SCSI_DPT_I2O=m
> CONFIG_SCSI_ADVANSYS=m
> CONFIG_SCSI_IN2000=m
> CONFIG_SCSI_AM53C974=m
> CONFIG_SCSI_MEGARAID=m
> CONFIG_SCSI_MEGARAID2=m
> CONFIG_SCSI_SATA=y
> CONFIG_SCSI_SATA_AHCI=m
> CONFIG_SCSI_SATA_SVW=m
> CONFIG_SCSI_ATA_PIIX=m
> CONFIG_SCSI_SATA_NV=m
> CONFIG_SCSI_SATA_QSTOR=m
> CONFIG_SCSI_SATA_PROMISE=m
> CONFIG_SCSI_SATA_SX4=m
> CONFIG_SCSI_SATA_SIL=m
> CONFIG_SCSI_SATA_SIS=m
> CONFIG_SCSI_SATA_ULI=m
> CONFIG_SCSI_SATA_VIA=m
> CONFIG_SCSI_SATA_VITESSE=m
> CONFIG_SCSI_BUSLOGIC=m
> # CONFIG_SCSI_OMIT_FLASHPOINT is not set
> CONFIG_SCSI_CPQFCTS=m
> CONFIG_SCSI_DMX3191D=m
> CONFIG_SCSI_DTC3280=m
> CONFIG_SCSI_EATA=m
> CONFIG_SCSI_EATA_TAGGED_QUEUE=y
> CONFIG_SCSI_EATA_LINKED_COMMANDS=y
> CONFIG_SCSI_EATA_MAX_TAGS=16
> CONFIG_SCSI_EATA_DMA=m
> CONFIG_SCSI_EATA_PIO=m
> CONFIG_SCSI_FUTURE_DOMAIN=m
> CONFIG_SCSI_FD_MCS=m
> CONFIG_SCSI_GDTH=m
> CONFIG_SCSI_GENERIC_NCR5380=m
> CONFIG_SCSI_GENERIC_NCR53C400=y
> CONFIG_SCSI_G_NCR5380_PORT=y
> # CONFIG_SCSI_G_NCR5380_MEM is not set
> CONFIG_SCSI_IBMMCA=m
> CONFIG_IBMMCA_SCSI_ORDER_STANDARD=y
> CONFIG_IBMMCA_SCSI_DEV_RESET=y
> CONFIG_SCSI_IPS=m
> CONFIG_SCSI_INITIO=m
> CONFIG_SCSI_INIA100=m
> CONFIG_SCSI_NCR53C406A=m
> CONFIG_SCSI_NCR_D700=m
> CONFIG_53C700_IO_MAPPED=y
> CONFIG_SCSI_NCR53C7xx=m
> CONFIG_SCSI_NCR53C7xx_sync=y
> CONFIG_SCSI_NCR53C7xx_FAST=y
> CONFIG_SCSI_NCR53C7xx_DISCONNECT=y
> CONFIG_SCSI_SYM53C8XX_2=m
> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
> CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
> CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
> # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
> CONFIG_SCSI_NCR53C8XX=m
> CONFIG_SCSI_SYM53C8XX=m
> CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
> CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
> CONFIG_SCSI_NCR53C8XX_SYNC=20
> # CONFIG_SCSI_NCR53C8XX_PROFILE is not set
> # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
> CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
> # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
> CONFIG_SCSI_MCA_53C9X=m
> CONFIG_SCSI_PAS16=m
> CONFIG_SCSI_PCI2000=m
> CONFIG_SCSI_PCI2220I=m
> CONFIG_SCSI_PSI240I=m
> CONFIG_SCSI_QLOGIC_FAS=m
> CONFIG_SCSI_QLOGIC_ISP=m
> CONFIG_SCSI_QLOGIC_FC=m
> # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
> CONFIG_SCSI_QLOGIC_1280=m
> CONFIG_SCSI_SEAGATE=m
> CONFIG_SCSI_SIM710=m
> CONFIG_SCSI_SYM53C416=m
> CONFIG_SCSI_DC390T=m
> # CONFIG_SCSI_DC390T_NOGENSUPP is not set
> CONFIG_SCSI_T128=m
> CONFIG_SCSI_U14_34F=m
> CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y
> CONFIG_SCSI_U14_34F_MAX_TAGS=8
> CONFIG_SCSI_ULTRASTOR=m
> CONFIG_SCSI_NSP32=m
> 
> 
>> I have a Dell 1550 Poweredge which uses a Perc3/DC SCSI raid card.  Seems
>> that it isn't anywhere in the supported list.  I wondered if there is some
>> documentation in adding drivers into a distro or rolling your own distro
>> with the drivers included.
>> 
> you should follow the build how-to on www.ipcop.org
> http://www.ipcop.org/modules.php?op=modload&name=phpWiki&file=index&pagename=H
> owToCompileAdditionalCode
> 
> Gilles
> 
> 

----- Original Message ----- 
From: "Heath Henderson" <he...@a5...>
To: <ipc...@li...>
Sent: Monday, February 26, 2007 10:10 PM
Subject: [IPCop-devel] Dell server SCSI driver


> Curious if there is a listing out there of the SCSI driver set included
with
> the current release?
>
this is drivers available on 2.4 kernel
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_PROBE_EISA_VL=y
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_BUILD_FIRMWARE is not set
CONFIG_AIC79XX_ENABLE_RD_STRM=y
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
CONFIG_SCSI_MEGARAID=m
CONFIG_SCSI_MEGARAID2=m
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_AHCI=m
CONFIG_SCSI_SATA_SVW=m
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_SATA_NV=m
CONFIG_SCSI_SATA_QSTOR=m
CONFIG_SCSI_SATA_PROMISE=m
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIL=m
CONFIG_SCSI_SATA_SIS=m
CONFIG_SCSI_SATA_ULI=m
CONFIG_SCSI_SATA_VIA=m
CONFIG_SCSI_SATA_VITESSE=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_FD_MCS=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_G_NCR5380_PORT=y
# CONFIG_SCSI_G_NCR5380_MEM is not set
CONFIG_SCSI_IBMMCA=m
CONFIG_IBMMCA_SCSI_ORDER_STANDARD=y
CONFIG_IBMMCA_SCSI_DEV_RESET=y
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_NCR_D700=m
CONFIG_53C700_IO_MAPPED=y
CONFIG_SCSI_NCR53C7xx=m
CONFIG_SCSI_NCR53C7xx_sync=y
CONFIG_SCSI_NCR53C7xx_FAST=y
CONFIG_SCSI_NCR53C7xx_DISCONNECT=y
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX=m
CONFIG_SCSI_SYM53C8XX=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
CONFIG_SCSI_MCA_53C9X=m
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PCI2000=m
CONFIG_SCSI_PCI2220I=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
# CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DC390T_NOGENSUPP is not set
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_NSP32=m


> I have a Dell 1550 Poweredge which uses a Perc3/DC SCSI raid card.  Seems
> that it isn't anywhere in the supported list.  I wondered if there is some
> documentation in adding drivers into a distro or rolling your own distro
> with the drivers included.
>
you should follow the build how-to on www.ipcop.org
http://www.ipcop.org/modules.php?op=modload&name=phpWiki&file=index&pagename=HowToCompileAdditionalCode

Gilles

Curious if there is a listing out there of the SCSI driver set included with
the current release?

I have a Dell 1550 Poweredge which uses a Perc3/DC SCSI raid card.  Seems
that it isn't anywhere in the supported list.  I wondered if there is some
documentation in adding drivers into a distro or rolling your own distro
with the drivers included.

Any support would be helpful.

Thanks


-- 
Heath Henderson
he...@a5...
--

Bugs item #1669360, was opened at 2007-02-26 19:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1669360&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: Security (Patches etc)
Group: 1.4.13
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bas van Schaik (bvanschaik)
Assigned to: Nobody/Anonymous (nobody)
Summary: Source restriction on portforward using alias iface fails

Initial Comment:
  Bug summary
As reported on the ipcop-user mailinglist by yours truly, on the 21st of February: any source restriction (both IP-address and network based) on a portforward using an alias interface doesn't work: IPCop still invites the whole world to use the port. Source restriction on the default interface _does_ work as expected.

Since I didn't receive any replies on my post on the mailinglist, this bug hasn't been confirmed by other users yet.


  Priority
I think this is a high priority security bug, since users expect IPCop to firewall traffic from the outside world, except for a given source IP or network. While this doesn't work as expected, users might be at risk without knowing so.


  Technical details/example:
Example assumptions:
eth0 = green = 172.26.5.254/255.255.255.0
eth1 = red = 213.154.245.184 (WAN)
eth1:2 = 213.154.245.181


This example uses port 3306 (MySQL) to illustrate the problem. Adding a portforward on a configured (red) alias using the IPCop webinterface results results in the forwarding table which can be found in the attachment. The actual and relevant iptables configuration:
# iptables -L -n -vv |grep "3306\|Chain" | grep -B1 3306
Chain PORTFWACCESS (1 references)
 0 0 ACCEPT tcp -- eth1 * 80.89.232.128 172.26.5.10 tcp dpt:3306

(note the first and second zero!)

and:
# iptables -t nat -L -n -vv |grep "3306\|Chain" | grep -B1 3306
Chain PORTFW (1 references)
 1 60 DNAT tcp -- * * 0.0.0.0/0 213.154.245.181 tcp dpt:3306 to:172.26.5.10:3306

(not the "1" and "60" here!)

At first sight, these rule seems to implement exactly what I requested IPCop to do. However, IPCop still accepts connections from a completely other IP:
# tcpdump -n dst port 3306
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
19:15:20.222292 IP 131.211.39.72.53908 > 213.154.245.181.3306: S 2495976934:2495976934(0) win 5840 <mss 1380,sackOK,timestamp 1555541156[|tcp]>
19:15:20.222344 IP 131.211.39.72.53908 > 172.26.5.10.3306: S 2495976934:2495976934(0) win 5840 <mss 1380,sackOK,timestamp 1555541156[|tcp]>
19:15:20.222508 IP 172.26.5.10.3306 > 131.211.39.72.53908: S 1370010404:1370010404(0) ack 2495976935 win 5792 <mss 1460,sackOK,timestamp 782705361[|tcp]>
(keeps going on...)

I'm not experienced enough to judge the iptables rules generated by IPCop, but there seems to be a rule somewhere in the filter table which accepts traffic from other sources than the configured one. 
Maybe a stupid question: why isn't source filtering implemented in the nat table, PORTFW chain? That chain seems to contain all manually configured portforwards, but doesn't perform any packet source filtering.

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

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

Feature Requests item #1668552, was opened at 2007-02-25 14:42
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=1668552&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: dpsims (dpsims)
Assigned to: Nobody/Anonymous (nobody)
Summary: Outbound traffic address

Initial Comment:
  Not sure how to do it, but it would be _very_ useful, if, when creating an alias forwarding rule via the GUI (i.e., having created an alias and then forwarding that alias to an internal host) that an iptables rule was created to also cause traffic _from_ that host to exit on the alias address....

  The downside would be the case where you have an alias/forward that allows traffic to different hosts on different ports... Perhaps it would be possible to add a tick box to the forward setup page which would make it optional...

  I would think that this would be fairly easy to do and it would be a big benefit when forwarding traffic to (for instance) a mail server or other server that needs bidirectional static NAT...

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

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

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: <ipc...@li...>
Sent: Sunday, February 25, 2007 12:22 PM
Subject: Re: [IPCop-devel] Fcron error/warn message in 1.4.13


> > In build environment it is set to cron.cron but not on installed
> > IPCop!?
>
> > Is there a reason the directory is set to root.root?
>
> > Achim
>
> Ok, I found the issue. In rootfiles /var/spool/cron is not included.
> With new.root and root.orig are included the directory is included too
> but without the owner/permissions.
>
> So to fix this, should I include the directory and place a chown call
> in upgrade script?
>
> I would change the owner to cron.cron (in upgrade script) as it is the
> owner/permissions set by lfs/fcron compilation.
>
> Achim
>
I check other directories not root:root for the same problem with help of
find/awk/sed/diff.
There is only 3 directories that are in this case
< /etc/snort/docs  drwxr-xr-x nobody nobody
< /var/proxy  drwxr-xr-x nobody nobody
< /var/spool/cron  drwxrwx--- cron cron

/etc/snort/docs is not installed
/var/proxy is created by apache and is not installed
so you should have find the only directory that need to be fixed

Gilles

> that's explain at the head of upgrade script.
> Maybe the name is not appropriate, fixbackup could be better?

> If a file include in backup need a fix, that's for upgrade.
> If the file is not include, that's only in update setup.

> I think each time we add something in upgrade, we will need to call upgrade
> in update setup.

> Gilles

Thanks Gilles for explanation. My changes (rootfiles, 1.4.14/setup)
are in 1.4 CVS now.

Achim

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Sunday, February 25, 2007 2:35 PM
Subject: Re: [IPCop-devel] Fcron error/warn message in 1.4.13


> >> I would change the owner to cron.cron (in upgrade script) as it is the
> >> owner/permissions set by lfs/fcron compilation.
> >>
> >> Achim
> >>
>
> > yes in updates/1.4.14/setup, not in src/scripts/upgrade
> > I am sure you know already
>
> > Gilles
>
> Ok, I will commit those changes. Well I really thought of
> src/scripts/upgrade to catch upgrades/backup-restores on later ipcop
> versions but you are right. The directory will be there already and
> only files inside the directory would change (at least I think that's
> the behavior!??).
>
> Achim
>
that's explain at the head of upgrade script.
Maybe the name is not appropriate, fixbackup could be better?

If a file include in backup need a fix, that's for upgrade.
If the file is not include, that's only in update setup.

I think each time we add something in upgrade, we will need to call upgrade
in update setup.

Gilles

>> > In build environment it is set to cron.cron but not on installed
>> > IPCop!?
>> 
>> > Is there a reason the directory is set to root.root?
>> 
>> > Achim
>> 
>> Ok, I found the issue. In rootfiles /var/spool/cron is not included.
>> With new.root and root.orig are included the directory is included too
>> but without the owner/permissions.
>> 
> Nice catch, we should care of that.

>> So to fix this, should I include the directory and place a chown call
>> in upgrade script?
>> 
>> I would change the owner to cron.cron (in upgrade script) as it is the
>> owner/permissions set by lfs/fcron compilation.
>> 
>> Achim
>> 

> yes in updates/1.4.14/setup, not in src/scripts/upgrade
> I am sure you know already

> Gilles

Ok, I will commit those changes. Well I really thought of
src/scripts/upgrade to catch upgrades/backup-restores on later ipcop
versions but you are right. The directory will be there already and
only files inside the directory would change (at least I think that's
the behavior!??).

Achim

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: <ipc...@li...>
Sent: Sunday, February 25, 2007 12:22 PM
Subject: Re: [IPCop-devel] Fcron error/warn message in 1.4.13


> > In build environment it is set to cron.cron but not on installed
> > IPCop!?
> 
> > Is there a reason the directory is set to root.root?
> 
> > Achim
> 
> Ok, I found the issue. In rootfiles /var/spool/cron is not included.
> With new.root and root.orig are included the directory is included too
> but without the owner/permissions.
> 
Nice catch, we should care of that.
> So to fix this, should I include the directory and place a chown call
> in upgrade script?
> 
> I would change the owner to cron.cron (in upgrade script) as it is the
> owner/permissions set by lfs/fcron compilation.
> 
> Achim
> 

yes in updates/1.4.14/setup, not in src/scripts/upgrade
I am sure you know already

Gilles

> In build environment it is set to cron.cron but not on installed
> IPCop!?

> Is there a reason the directory is set to root.root?

> Achim

Ok, I found the issue. In rootfiles /var/spool/cron is not included.
With new.root and root.orig are included the directory is included too
but without the owner/permissions.

So to fix this, should I include the directory and place a chown call
in upgrade script?

I would change the owner to cron.cron (in upgrade script) as it is the
owner/permissions set by lfs/fcron compilation.

Achim

----- Original Message ----- 
From: <pct...@ju...>
To: <ipc...@li...>
Sent: Sunday, February 25, 2007 11:22 AM
Subject: Re: [IPCop-devel] Changes aren't being saved when building iso..


...
>   Ok, so I am adding some small packages to the build chain.. I have
> hacked up some make files from exsisting files, the packages build and
> install exactly as they should.  But they do not show up in the final
> product at all..
You should follow the building how-to
http://www.ipcop.org/modules.php?op=modload&name=phpWiki&file=index&pagename=HowToCompileAdditionalCode

compile you code,
take the resulting log/TARGET files,
comment in that log the files you don't want to include and add those lists
in src/ROOTFILES.i386

Gilles

>   I have figured out much in the way of building IpCop, however..   thing seems to slip my grasp..  Whent he iso is built it doesn't save
> any of my changes.
>   Any help would be appreciated.
>
>  Joshua
>
Change should apply to cvs part and be installed during build process in=

build directory.

Where are your changes?
If a TARGET is already compiled, you would need to suppress the
corresponding log/TARGET to rebuild that part.
Basically, you would need to change src/ROOTFILES.i386 to include more
files
in iso.
  Ok, so I am adding some small packages to the build chain.. I have
hacked up some make files from exsisting files, the packages build and
install exactly as they should.  But they do not show up in the final
product at all..
  So I tried to make the ROOTFILES.i386 reflect everything and that
failed.  I really only need to include the files in which I have
added..  Is there an easier way to do this?
  Another example is that I changed squid to 2.6 from 2.5 to try and
get around a problem. Installing dansguardian on the said system causes
it to not work ( dg that is ) because they aren't built for the same
arch.. So I have to rebuild d's guardian..  I figured I would place
some other usefull stuff into while I was at it. wget iptraf etc..  All
of which work fine, until it biuld the ISO that has nothing in it that
I added.. =


Joshua


Sometime, directory are include, for example lib/modules/KVER/kernel or
usr/share/zoneinfo/posix so every files include in this directory is
include
in iso.

If a change is in a script installed during build, you should rebuild th=
at
part
suppress log/initscripts to include changed src/rc.d scripts
If the script is installed by lfs/stage2, actually, you would be forced =
to
rebuild all or apply the change by hand in build/usr/local/bin and rebui=
ld
the iso with a simple ./make.sh build

Gilles


________________________________________________________________________=

FREE Reminder Service - NEW from AmericanGreetings.com
Click HERE and never forget a Birthday or Anniversary again!
http://track.juno.com/s/lc?s=3D197335&u=3Dhttp://www.americangreetings.c=
om/products/online_calendar.pd?c=3Duol5752

----- Original Message ----- 
From: <pct...@ju...>
To: <IPC...@li...>
Sent: Sunday, February 25, 2007 10:00 AM
Subject: [IPCop-devel] Changes aren't being saved when building iso..


>   I have figured out much in the way of building IpCop, however..  One
> thing seems to slip my grasp..  Whent he iso is built it doesn't save
> any of my changes.
>   Any help would be appreciated.
>
>  Joshua
>
Change should apply to cvs part and be installed during build process in
build directory.

Where are your changes?
If a TARGET is already compiled, you would need to suppress the
corresponding log/TARGET to rebuild that part.
Basically, you would need to change src/ROOTFILES.i386 to include more files
in iso.
Sometime, directory are include, for example lib/modules/KVER/kernel or
usr/share/zoneinfo/posix so every files include in this directory is include
in iso.

If a change is in a script installed during build, you should rebuild that
part
suppress log/initscripts to include changed src/rc.d scripts
If the script is installed by lfs/stage2, actually, you would be forced to
rebuild all or apply the change by hand in build/usr/local/bin and rebuild
the iso with a simple ./make.sh build

Gilles

  I have figured out much in the way of building IpCop, however..  One
thing seems to slip my grasp..  Whent he iso is built it doesn't save
any of my changes.
  Any help would be appreciated.

 Joshua



________________________________________________________________________=

FREE Reminder Service - NEW from AmericanGreetings.com
Click HERE and never forget a Birthday or Anniversary again!
http://track.juno.com/s/lc?s=3D197335&u=3Dhttp://www.americangreetings.c=
om/products/online_calendar.pd?c=3Duol5752

> -----Original Message-----
> From: ipc...@li... [mailto:ipcop-devel-
> bo...@li...] On Behalf Of Charlie Lehardy
> Sent: Saturday, February 24, 2007 1:45 PM
> To: IPC...@li...
> Subject: [IPCop-devel] Feature request: IDS 3-strikes rule
> 
> 
>  Would it be possible to have IPCOP keep track of the source IP
>  address of sites that are attacking the firewall, with an option to
>  block an IP address after X (user specified) attempts for Y (user
>  specified) minutes? It seems to me that there ought to be a way to
>  discourage people who keep taking a sledge hammer to my front door.
> 
>  Apologies in advance if there is already a way to implement this.
>  Thanks for your consideration.
> 
>  Charlie Lehardy
> 


You can use an add on.
Modname: Guardian for Ipcop
By Markus Hoffmann
Here:
http://www.mhaddons.tk/

I was looking for the same thing and a helpful person at GRC.com NNTP groups
pointed it out to me.

 Would it be possible to have IPCOP keep track of the source IP
 address of sites that are attacking the firewall, with an option to
 block an IP address after X (user specified) attempts for Y (user
 specified) minutes? It seems to me that there ought to be a way to
 discourage people who keep taking a sledge hammer to my front door.

 Apologies in advance if there is already a way to implement this.
 Thanks for your consideration.

 Charlie Lehardy

How do,

On Fri, 2007-02-23 at 10:43 -0800, David W Studeman wrote:

> My 1.4.13 also shows the old daylight savings time switch here in the US. I 
> noticed that my SuSE 10.2 does indeed show Mar 11th and Nov 4th as the switch 
> times in the US. Of course Arizona does NOT ever change time.

Any supported SuSE version with it's patches up to date, will be good to
go come March 11th ;-)

> 
> Dave

taharka

Lexington, Kentucky U.S.A.

Hi,

since we upgrade to fcron-3.0.1 in 1.4.13 there is always an
error/warn message when you run fcrontab (-z etc.):
   Can't create file rm.root: Permission denied

I checked fcron source code, fcrontab wants to write this file to
/var/spool/cron/. As this directory is owned by root.root (with write
permissions to root only) and fcron is running as cron.cron fcrontab
is not able to write this file. This file (and another 'new.root'
file) is a flage file for the fcron deamon.

This error was even in fcron 2.x but there where no error message
about it. This may is the reason why fcron (deamon) was a bit buggy on
ipcop!?

When I set the owner: cron and group: root, fcrontab runs fine (== no
message).
In build environment it is set to cron.cron but not on installed
IPCop!?

Is there a reason the directory is set to root.root?

Achim

----- Original Message ----- 
From: "Brandon Sussman" <Br...@We...>
To: "Gilles Espinasse" <g....@fr...>
Sent: Friday, February 23, 2007 5:57 PM
Subject: Re: [IPCop-devel] TIMEZONE INFO and I am brain dead!


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gilles Espinasse wrote on 02/23/2007 07:49 AM:
>
>
>
> | I don't know how but there is probably an error with your way to check.
>
>
>
> My ISO contains a file called ipcop-1.4.13.tgz
>
> The tar file contains a file called /etc/localtime.
>
> I could be wrong but I do believe this is the file that my ipcop system
uses
> to manage local time.
>
> This file seems to be on my ipcop machine.
>
> I move the file to a machine that has zdump.
>
> It contains the lines previously reported.
>
> Not sure how there could be much error in this method of checking.
>
> Please explain.
>
>
Before the install and in ipcop-<VERSION>.tgz /etc/localtime is a symlink
./make.sh shell
Feb 23 18:50:19: Machine is ix86 (or equivalent)
Feb 23 18:50:19: Resetting our nice level to 10
Feb 23 18:50:19: Checking if we're running as root user
Feb 23 18:50:19: Checking for necessary space on disk
Feb 23 18:50:19: Building Linux From Scratch system
Entering to a shell inside LFS chroot, go out with exit
root:/# ls -l /etc/localtime
lrwxrwxrwx 1 root root 29 Feb 23 16:45 /etc/localtime ->
../usr/share/zoneinfo/Factory

barton 1.4b # ls build/install/cdrom
COPYING  README.txt  boot  doc  dosutils  images  ipcop-1.4.14.tgz
barton 1.4b # tar -tvzf build/install/cdrom/ipcop-1.4.14.tgz | grep
localtime
lrwxrwxrwx root/root         0 2007-02-23 17:56 etc/localtime ->
../usr/share/zoneinfo/Factory
-r--r--r-- root/root       2350 2007-02-23 17:02
usr/lib/perl5/5.8.5/Time/localtime.pm
-r--r--r-- root/root        337 2007-02-23 17:02
usr/lib/perl5/5.8.5/i386-linux/auto/POSIX/localtime.al

Depending of the way you extract localtime to the other machine, you may
have move a symlink.
If you tar the file, that's what happen by default

I will update glibc-2.3.3 timezone (was tzdata2003c) with tzdata2007b.tar.gz
and provide zdump on next release for the curious.

Gilles