policy...
...of freezing ports - why? Whenever we are waiting for the new release of FreeBSD, now is 8.3, ports are frozen. There are no updates and in case of 8.3 coming release is time about three months. Could someone explain, please why is this freezing very important because soon after release came out there will be s many ports for update. On my computaer I spent about two or three days for updating and update is also on the new release. Thank you. Mitja http://jpgmag.com/people/lumiwa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: policy...
Ports are frozen, a snapshot of the ports tree is made for use on their build boxes to make packages for the mirrors. Assuming no issues have been discovered on the build servers (broken ports that need to be fixed) it will be packaged with 8.3-RELEASE. I'm probably missing several important details, but this is the gist of it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: policy...
On Tuesday 17 April 2012 09:43:50 Mark Felder wrote: Ports are frozen, a snapshot of the ports tree is made for use on their build boxes to make packages for the mirrors. Assuming no issues have been discovered on the build servers (broken ports that need to be fixed) it will be packaged with 8.3-RELEASE. I'm probably missing several important details, but this is the gist of it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Thank you very much. I just was wondering why are after the realese is out so many port to rebuilt (as I wrote for two, three days if is going realtively smooth). Mitja http://jpgmag.com/people/lumiwa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
OT: Root access policy
For the first time, a customer is asking me for root access to said customer's servers. Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Is this that simple and clear cut? Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... I'd appreciate comments/experience/advice from the wise... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. Customer + root@server == !go; :-) Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Fully correct. Check the contract you made with the customer regarding responsibility and conclusions. Is this that simple and clear cut? I'd think so. Maybe changing the contract is required. Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... You could have better success using sudo. Make sure the customer is allowed to sudo command. The sudo program will log _all_ things the customer does, so you can be sure you can review actions. Furthermore you don't need to give him the _real_ root password. He won't be able to su root or to login as root, _real_ root. But he can use the sudo prefix to issue commands with root privileges. I'd appreciate comments/experience/advice from the wise... Just a thought: Parallel administration (you _and_ the customer), both capable of using the power of the root password, can lead to trouble. Avoid it whenever possible, use sudo to satisfy the demands of the customer. And make sure that - as he now posesses immense power - you regulate the responsibilities by CONTRACT: _you_ are not responsible if he does sudo rm -rf / or something similar. I'd give the customer only that much access as he actually needs. Role based models such as they can be done without root passwords (tools: sudo, super) can help here. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On 29/12/2011 09:01, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Is this that simple and clear cut? Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... I'd appreciate comments/experience/advice from the wise... Where I used to work, customers were given root level access to their servers by default. We did insist on a secure access method using SSH keys and we also insisted that root level access was allowed only to specific named people each using their own SSH key (so you always had to login as an unprivileged user before getting root access). This allowed a good level of audit trail and the ability to identify exactly who had done what. On the whole, this worked well. Most customers are after all motivated to keep their servers running well and securely and would very rarely use their root level access, since we would provide all the routine management functions as part of the service. Occasionally there would be customers that we pretty much as capable as we were, and for those we were happy to let them do their own thing so long as they conformed to our security standards. Occasionally there were the odd customers who thought they were much more capable than they were. Generally there would be a cock-up, which we would then sort out at the customers expense, after which things tended much more towards the customer leaving it all to us. (Usually this would happen during the system setup or testing phase so no embarrassing service outages.) On the other hand, we tended not to give customers any access to firewalls or network switches or other network infrastructure, nor indeed to monitoring or backup or other adjunct services. The important thing, especially if you have stringent service level guarantees in your contracts, is to disclaim any liabilities due to outages or other problems caused by customer action. Which implies that it is vital to have good audit data that can identify the individual responsible for any action. You're also justified in raising your prices to cover yourself against potential losses (reputational or otherwise) due to customer actions. Your mileage may vary -- the clients at that job were mostly finance or similar companies and tended to have quite formal change-management regimes in any case. Other sectors may be a lot more gung-ho... Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: OT: Root access policy
On Thursday 29 December 2011, Damien Fleuriot wrote: [snip] sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! [snip] Say the customer can sudo commands located in /usr/local/libexec/CUSTOMER/ All he has to do is write a simple link to sh/bash, and sudo it. But if it's possible to determine exactly what commands the customer needs to run as root then putting suitable incantations into /usr/local/etc/sudoers should prevent the customer from being able to use tricks like that. -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: OT: Root access policy
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Polytropon Sent: Thursday, December 29, 2011 9:58 AM To: Carl Johnson Cc: freebsd-questions@freebsd.org Subject: Re: OT: Root access policy On Thu, 29 Dec 2011 09:15:45 -0800, Carl Johnson wrote: Damien Fleuriot m...@my.gd writes: On 12/29/11 10:58 AM, Polytropon wrote: On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. snip Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... You could have better success using sudo. Make sure the customer is allowed to sudo command. The sudo program will log _all_ things the customer does, so you can be sure you can review actions. Furthermore you don't need to give him the _real_ root password. He won't be able to su root or to login as root, _real_ root. But he can use the sudo prefix to issue commands with root privileges. sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! The sudoers manpage mention the noexec option which is designed to help with the first problem. They also show an example using !SHELLS which can help with the second. It's also worth mentioning super again - as an alternative to sudo. But after all, if restricted in any way, both of them are _not_ requivalent to full root access (equals: root + root's password) which the customer initially demanded. I highly recommend reading audit(4) and then audit(8) (in that order). This will catch more security instances than simply relying on sudo(8) logging -- which won't catch any commands once the user has become root (ala sudo su - for example). Once upon a time (RELENG_4), we used a kernel module named lrexec which logged all system calls to exec(3) family of functions, but it was too verbose. audit(4) replaces our need for lrexec. -- Devin -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On 12/29/11 10:58 AM, Polytropon wrote: On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. Customer + root@server == !go; :-) Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Fully correct. Check the contract you made with the customer regarding responsibility and conclusions. Another way of doing things would be to give the customer root access on the server, if it's entirely his, and relinquish your own root access. No more root access for you, no accountability considerations. Is this that simple and clear cut? I'd think so. Maybe changing the contract is required. Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... You could have better success using sudo. Make sure the customer is allowed to sudo command. The sudo program will log _all_ things the customer does, so you can be sure you can review actions. Furthermore you don't need to give him the _real_ root password. He won't be able to su root or to login as root, _real_ root. But he can use the sudo prefix to issue commands with root privileges. sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! I'd appreciate comments/experience/advice from the wise... Just a thought: Parallel administration (you _and_ the customer), both capable of using the power of the root password, can lead to trouble. Avoid it whenever possible, use sudo to satisfy the demands of the customer. And make sure that - as he now posesses immense power - you regulate the responsibilities by CONTRACT: _you_ are not responsible if he does sudo rm -rf / or something similar. Sadly, this brings in the burden of proof. As in, prove that *he* didn't issue the dumb command, the customer did. This model is endangered by the commands I cited above :/ I'd give the customer only that much access as he actually needs. Role based models such as they can be done without root passwords (tools: sudo, super) can help here. That's more like it indeed, however it still poses security threats. Say the customer can sudo commands located in /usr/local/libexec/CUSTOMER/ All he has to do is write a simple link to sh/bash, and sudo it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On Thu, 29 Dec 2011 11:23:31 +0100, Damien Fleuriot wrote: On 12/29/11 10:58 AM, Polytropon wrote: On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Fully correct. Check the contract you made with the customer regarding responsibility and conclusions. Another way of doing things would be to give the customer root access on the server, if it's entirely his, and relinquish your own root access. No more root access for you, no accountability considerations. Yes, that's the other option. Full responsibility to the customer (as per his demand of a root password), no responsibility to the administrator anymore. sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! S!!! Don't tell them! :-) I'd appreciate comments/experience/advice from the wise... Just a thought: Parallel administration (you _and_ the customer), both capable of using the power of the root password, can lead to trouble. Avoid it whenever possible, use sudo to satisfy the demands of the customer. And make sure that - as he now posesses immense power - you regulate the responsibilities by CONTRACT: _you_ are not responsible if he does sudo rm -rf / or something similar. Sadly, this brings in the burden of proof. As in, prove that *he* didn't issue the dumb command, the customer did. This model is endangered by the commands I cited above :/ Ah s!!! Don't point at it again! :-) But you're fully right: The logging has ways to get around it. I think super can be used to give a narrowed-down access, but that's not comparable to the customer demanding root access (which it wouldn't be). I'd give the customer only that much access as he actually needs. Role based models such as they can be done without root passwords (tools: sudo, super) can help here. That's more like it indeed, however it still poses security threats. True, it does. You won't have full security as long as the customer is able to do root-related things. Say the customer can sudo commands located in /usr/local/libexec/CUSTOMER/ All he has to do is write a simple link to sh/bash, and sudo it. Stop that! You're hacking the system by telling all the secret things! :-) Depending on the skills of the particular customer, and of course in regards of what he _intends_ to do himself, there are many possibilities. They even get enlarged when the customer gives the root password to a 3rd person, intendedly or by careless actions. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On Thu, Dec 29, 2011 at 10:01 AM, Irk Ed irked7...@gmail.com wrote: For the first time, a customer is asking me for root access to said customer's servers. Are we talking about jail(8)- or server-level root access? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On Thu, 29 Dec 2011 09:15:45 -0800, Carl Johnson wrote: Damien Fleuriot m...@my.gd writes: On 12/29/11 10:58 AM, Polytropon wrote: On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. snip Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... You could have better success using sudo. Make sure the customer is allowed to sudo command. The sudo program will log _all_ things the customer does, so you can be sure you can review actions. Furthermore you don't need to give him the _real_ root password. He won't be able to su root or to login as root, _real_ root. But he can use the sudo prefix to issue commands with root privileges. sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! The sudoers manpage mention the noexec option which is designed to help with the first problem. They also show an example using !SHELLS which can help with the second. It's also worth mentioning super again - as an alternative to sudo. But after all, if restricted in any way, both of them are _not_ requivalent to full root access (equals: root + root's password) which the customer initially demanded. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
Damien Fleuriot m...@my.gd writes: On 12/29/11 10:58 AM, Polytropon wrote: On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. snip Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... You could have better success using sudo. Make sure the customer is allowed to sudo command. The sudo program will log _all_ things the customer does, so you can be sure you can review actions. Furthermore you don't need to give him the _real_ root password. He won't be able to su root or to login as root, _real_ root. But he can use the sudo prefix to issue commands with root privileges. sudo su - or sudo sh and the customer gets a native root shell which does *not* log commands ! The sudoers manpage mention the noexec option which is designed to help with the first problem. They also show an example using !SHELLS which can help with the second. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: Root access policy
On Dec 29, 2011, at 4:01 AM, Irk Ed wrote: For the first time, a customer is asking me for root access to said customer's servers. Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Is this that simple and clear cut? Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... I'd appreciate comments/experience/advice from the wise... Call me paranoid but is your contract near term end? In my experience this is usually a precursor to a end of year cost cutting service provider change. Specifically someone in sales's second cousin's nephew who saw a linux server once and thinks he's an expert. I recommend that you complete a backup of everything prior to granting them sudo access. Possibly even run am md5sum against all important config files and save that in your back up as well. Then give them well written explanation of why sudo is superior or at least safer to direct root access. Regards, Mikel King BSD News Network http://bsdnews.net skype: mikel.king http://twitter.com/mikelking ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd.org maillist mx discard policy
Hello list, My question is regarding official maillist smtp servers. I'm trying to subscribe on security-notifications, but (for some reasons) our outgoing MX has no PTR record and mx1.freebsd.org rejects my message: Reporting-MTA: dns; xxx Arrival-Date: Mon, 16 Aug 2010 17:18:39 +0400 (MSD) Final-Recipient: RFC822; freebsd-security-notifications-requ...@freebsd.org Action: delayed Status: 4.7.1 Remote-MTA: DNS; mx1.freebsd.org Diagnostic-Code: SMTP; 450 4.7.1 Client host rejected: cannot find your hostname, [x.x.x.x] Last-Attempt-Date: Mon, 16 Aug 2010 21:24:36 +0400 (MSD) I have the SPF record set up for our domain which designates our external IP as a valid sender address for the domain, but I still get rejected. So, the question is: do the freebsd.org maillist servers follow SPF records or PTR record is mandatory? TIA. -- Best regards, Jeff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd.org maillist mx discard policy
On 19/08/2010 07:54, Jeff Laine wrote: So, the question is: do the freebsd.org maillist servers follow SPF records or PTR record is mandatory? The PTR is mandatory. The vast majority of SMTP senders without proper PTR records are zombie machines spreading spam. Anyone running a real mail system should be capable of arranging for a correct PTR in the DNS -- if they aren't then they have no business at the controls of a MTA. As far as I know, the FreeBSD.org mailers don't pay much attention to SPF -- generally the accepted practice seems to be to use SPF as part of computing Spam scores, but not to make accept/reject decisions solely based on SPF. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
WFRG Personal Use Policy
Personal Use Program Here's how it works... WFRG loves wood flooring. We develop many unique wood flooring products, several of which have become our personal favorites. We are so excited about these favorites that we would like to share them with you. And what better way to do so than to offer them to you for your personal use at discounted prices? Here's how our Personal Use program works: Note: This program is available only to Registered WFRG Design Professionals. Personal use means flooring that is going to be installed into the residence in which you live; it is NOT flooring being installed anywhere else or being resold. At the time of order we will ask that you attest to this and also request that you e-mail us a photo of the installation once completed. Itrsquo;s a great way to share our excitement! Click here for FREE Architectural Folder Dear design professional, If you are receiving this email, then you are on the Wood Floor Resource Group's mailing list. We know that for some, mailing list is a bad word that implies spam, junk mail, and other inconveniences. We consider having your name on our list a privilege which we will work to preserve by not abusing it! While we seek to educate and inform, lest anyone forget, we are in the business of selling wood flooring! If you have a need for wood flooring for your projects, please visit our website at www.woodfloorrg.com or simply pick up the phone and call us at 609.589.3100 x149. Just a few Personal Use Flooring Products discounted below $2.00 Square Foot: Bubinga Afrormosia Shedua Click here for complete list More Flooring Available -Handscraped -Prefinished Solids -FSC Exotic engineered -Recycled Domestic engineered Click here for complete list Sent By: Wood Floor Resource Group 115 Twinbridge Drive Pennsauken NJ 08110 USA To view as a web page press on or copy this link into your browsers address bar https://www.SwiftPage3.com/speasapage.aspx?X=2V0WBIJIHVFHUH3K000SX6 If you prefer not to receive future e-mails of this type, please copy to your browser or press on this link http://www.SwiftPage3.com/SpeSupIt.aspx?X=2V0WBIJIHVFHUH3K000SX6Addr=freebsd-questions~~2freebsd.org; to unsubscribe. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
WFRG Personal Use Policy
Personal Use Program Here's how it works... WFRG loves wood flooring. We develop many unique wood flooring products, several of which have become our personal favorites. We are so excited about these favorites that we would like to share them with you. And what better way to do so than to offer them to you for your personal use at discounted prices? Here's how our Personal Use program works: Note: This program is available only to Registered WFRG Design Professionals. Personal use means flooring that is going to be installed into the residence in which you live; it is NOT flooring being installed anywhere else or being resold. At the time of order we will ask that you attest to this and also request that you e-mail us a photo of the installation once completed. Itrsquo;s a great way to share our excitement! Click here for FREE Architectural Folder Dear design professional, If you are receiving this email, then you are on the Wood Floor Resource Group's mailing list. We know that for some, mailing list is a bad word that implies spam, junk mail, and other inconveniences. We consider having your name on our list a privilege which we will work to preserve by not abusing it! While we seek to educate and inform, lest anyone forget, we are in the business of selling wood flooring! If you have a need for wood flooring for your projects, please visit our website at www.woodfloorrg.com or simply pick up the phone and call us at 609.589.3100 x149. Just a few Personal Use Flooring Products discounted below $2.00 Square Foot: Bubinga Afrormosia Shedua Click here for complete list More Flooring Available -Handscraped -Prefinished Solids -FSC Exotic engineered -Recycled Domestic engineered Click here for complete list Sent By: Wood Floor Resource Group 115 Twinbridge Drive Pennsauken NJ 08110 USA To view as a web page press on or copy this link into your browsers address bar https://www.SwiftPage3.com/speasapage.aspx?X=2V0WBIJIHVFHUH3K00W4WA If you prefer not to receive future e-mails of this type, please copy to your browser or press on this link http://www.SwiftPage3.com/SpeSupIt.aspx?X=2V0WBIJIHVFHUH3K00W4WAAddr=questions~~2freebsd.org; to unsubscribe. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: WFRG Personal Use Policy
Now FreeBSD with a unique wood floor, that is a very exciting prospect! Olivier I know, I know, don't feed them, but I think it is the right time tio offer beasty a new home! :)) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
PXE + sysinstall(8) install.cfg: DHCP Attribute to map install config/policy to system MAC?
All:
The install.cfg mechanism is pretty wicked.
Unfortunately, there doesn't seem to be a really efficient way
to provide new clients (or class of clients) an install.cfg
without rebuilding an MFSROOT image.
At least with pxeboot(8), in TFTP-only-mode, using
dhcpd.conf(5) client{} entries, there isn't a way
to differentiate policies.
It's just going to go looking for /boot/loader.rc
and /boot/loader.conf from wherever DHCP told PXE
to fetch pxeboot(8) from.
From there, you need to custom compile a 5 meg
mfsroot image for each [class of] client.
With an NFS stage-2 boot, I suppose you could set:
option root-path /export/${client}Root etc.,
but then your 5 meg mfsroot is just extracted
1-per-client.
Still seems a bit ugly. It seems like we could teach
sysinstall(8) to fetch install.cfg by some standard
mechanism.
Possibly a TFTP or NFS URL passed from the DHCP server
- boot loader - kernel sysctl - sysinstall(8).
For example, the Sun SPARC4s would TFTP fetch their
stage 1 boot loader via TFTP with a filename req
of their MAC address in HEX format, so one could
just put symlinks in place.
Thoughts or other ideas?
~BAS
PS: our in-tree tftpd(8) is an unending source of sorrow and misery and
clinical despair. ports/net/freebsd-tftp is a lifesaver (it actually
has debugging)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: PXE + sysinstall(8) install.cfg: DHCP Attribute to map install config/policy to system MAC?
On 21/04/10 21:59, Brian A. Seklecki (CFI NOC) wrote: All: The install.cfg mechanism is pretty wicked. Unfortunately, there doesn't seem to be a really efficient way to provide new clients (or class of clients) an install.cfg without rebuilding an MFSROOT image. Possibly a TFTP or NFS URL passed from the DHCP server - boot loader - kernel sysctl - sysinstall(8). Thoughts or other ideas? You can configure sysinstall in your install.cfg to execute shell commands, including any fetch-like command. Some scripting should be possible to do what you require. I wrote about it here: http://www.locolomo.org/howto/pxeboot/automatic-installation.html However, I never really went on and tested this, let me know if this works. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
policy-violation found in sent message
Attention: freebsd-questions@freebsd.org A policy-violation was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching its destination. The policy-violation was reported to be: SCR files not allowed per Company security policy Please contact your IT support personnel with any queries regarding this policy. Your message was sent with the following envelope: MAIL FROM: freebsd-questions@freebsd.org RCPT TO: gifav...@unsl.edu.ar ... and with the following headers: --- MAILFROM: freebsd-questions@freebsd.org RCPTTO: gifav...@unsl.edu.ar IP-Addr: 113.22.65.102 Received: from unknown (HELO freebsd.org) (113.22.65.102) by inter11.unsl.edu.ar with SMTP; 8 Sep 2009 04:21:44 -0400 From: freebsd-questions@freebsd.org To: gifav...@unsl.edu.ar Subject: Date: Tue, 8 Sep 2009 15:21:37 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0011_C7647978.0EBC1B21 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Policy Kit - Not running
I'm running FBSD7 stable and I can't find out why policy kit won't run even though I have it enabled in rc.conf: dbus_enable=YES hald_enable=YES polkitd_enable=YES I can see dbus and hald but not polkitd nor do I see any error messages. Strange! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd6.2-stable + ipfilter + policy routing mbuf leak
Hi all, I have a server running 6.2-stable that experiences mbuf leakage if I perform policy routing with ipfilter. This is independent of the hardware as I have moved the disk to a different machine with different MB, NICs etc and had the same result. The server is running quagga, postfix and ipfilter for some basic firewalling. The policy routing was to route outgoing web traffic to a second internet link. I have been running the same setup for several years on a 4.11 machine without any problems. Can anyone confirm this problem? Cheers, Colin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Policy - based Routing problem Need help
Thank you very much,
Relaying on your help reach to success but rules differ from yours a little
bit. My working rules listed below:
ipfw add fwd A all from ${inet1}:${imask1} to any out recv ${iif1}
ipfw add fwd B all from ${inet}:${imask} to any out recv ${iif}
ipfw add fwd G all from any to ${inet1}:${imask1} out via ${iif1}
ipfw add fwd H all from any to ${inet}:${imask} out via ${iif}
ipfw add fwd A all from ${onet1}:${omask1} to any out
ipfw add fwd B all from ${onet}:${omask} to any out
ipfw add fwd A all from ${inet1}:${imask1} to any out
ipfw add fwd B all from ${inet}:${imask} to any out
The only problem last is when someone (from provider A) try to access ftp
server via B it connects but didn't do Get Directory command. Ipfw doesn't
matter I checked. I think it is specification of ftp- data 20 port
(connection opening problem). Can you describe me how it take place via 20
port or find the wrong line in ipfw fwd rules?
Best regards,
Narek
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Monday, July 30, 2007 2:02 AM
To: Narek Gharibyan
Subject: Re: Policy - based Routing problem Need help
Narek Gharibyan wrote:
Yes your written rules are correct, You think exactly
I want to do ALSO
1. Packets coming from ISP-B (B network)into C SHOULD go out only via xx0
(as they came)
# make sure WE can talk to the back nets
# and ourself
ipfw add 1 allow ip from any to any via lo0
ipfw add 2 allow ip from me to G
ipfw add 3 allow ip from me to H
# the next 2 rules are not actually needed as any packets
# going to G and H will go the right way anyhow.
# ipfw add 4 fwd (G) ip from any to G out recv xx0
# ipfw add 5 fwd (H) ip from any to H out recv xx1
# The next rules ARE needed.
ipfw add 6 fwd (A) ip from G to any out recv yy0
ipfw add 7 fwd (B) ip from H to any out recv yy1
ipfw add 8 fwd (A) ip from (C) to any out
ipfw add 9 fwd (B) ip from (D) to any out
2. Packets coming from ISP-A (A network) into D Should go out only via xx1
(as they came)
Saying by another words packets should leave my network via interface they
came.
3. Packets coming from E should go out via xx0
4. Packets coming from F should go out via xx1
Also I try from inside to forward packets without default gateway using
via
A or B with the commands
Ipfw add fwd A all from G to any xmit (or via) xx0
and it didn't work, I've compiled my kernel with IPFIREWALL,
IPFIREWALL_FORWARD, and set net.inet.ip.forwarding=1 in sysctl.conf.
Surely
I will try your configuration on Monday, but it seems ipfw fwd nothing do
forwarding. So how to write for reaching the results (1.,2.,3.,4.)?
Regards,
Narek
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 29, 2007 1:49 PM
To: Narek Gharibyan
Subject: Re: Policy - based Routing problem Need help
Narek Gharibyan wrote:
The right drawing is that one below
___ ___
-[ISP-A](A)(C)[xx0 yy0](E)--(G)[NAT]
[ FBSD ][ Windows ](X)-LAN
-[ISP-B](B)(D)[xx1 yy1](F)--(H)[NAT]
~~~ ~~~
We can't use only FreeBSD box, we need also use Windows box, due to our
company's policy. So you suggestion is not an option. I think we need a
different solution.
ok.
now that we have established the exact layout,
what is it exactly that you want to do?
I gather that you want packets that come into D to go out of F
and packets that come in through C should go out via E
this is achieved by:
ipfw add 1 fwd (G) ip from any to G out recv xx0
ipfw add 2 fwd (H) ip from any to H out recv xx1
what else do you wish it to do?
Regards,
Narek
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy - based Routing problem Need help
Narek Gharibyan wrote:
Thank you very much,
Relaying on your help reach to success but rules differ from yours a little
bit. My working rules listed below:
ipfw add fwd A all from ${inet1}:${imask1} to any out recv ${iif1}
ipfw add fwd B all from ${inet}:${imask} to any out recv ${iif}
the following two rules shouldnto be needed if your routes are correct.
ipfw add fwd G all from any to ${inet1}:${imask1} out via ${iif1}
ipfw add fwd H all from any to ${inet}:${imask} out via ${iif}
I don't know what onet is..
ipfw add fwd A all from ${onet1}:${omask1} to any out
ipfw add fwd B all from ${onet}:${omask} to any out
ipfw add fwd A all from ${inet1}:${imask1} to any out
ipfw add fwd B all from ${inet}:${imask} to any out
The only problem last is when someone (from provider A) try to access ftp
server via B it connects but didn't do Get Directory command. Ipfw doesn't
matter I checked. I think it is specification of ftp- data 20 port
(connection opening problem). Can you describe me how it take place via 20
port or find the wrong line in ipfw fwd rules?
ftp is a problem as it negotiates new ports for data.
That is why people use Passive mode FTP. it doesn't do that.
Best regards,
Narek
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Monday, July 30, 2007 2:02 AM
To: Narek Gharibyan
Subject: Re: Policy - based Routing problem Need help
Narek Gharibyan wrote:
Yes your written rules are correct, You think exactly
I want to do ALSO
1. Packets coming from ISP-B (B network)into C SHOULD go out only via xx0
(as they came)
# make sure WE can talk to the back nets
# and ourself
ipfw add 1 allow ip from any to any via lo0
ipfw add 2 allow ip from me to G
ipfw add 3 allow ip from me to H
# the next 2 rules are not actually needed as any packets
# going to G and H will go the right way anyhow.
# ipfw add 4 fwd (G) ip from any to G out recv xx0
# ipfw add 5 fwd (H) ip from any to H out recv xx1
# The next rules ARE needed.
ipfw add 6 fwd (A) ip from G to any out recv yy0
ipfw add 7 fwd (B) ip from H to any out recv yy1
ipfw add 8 fwd (A) ip from (C) to any out
ipfw add 9 fwd (B) ip from (D) to any out
2. Packets coming from ISP-A (A network) into D Should go out only via xx1
(as they came)
Saying by another words packets should leave my network via interface they
came.
3. Packets coming from E should go out via xx0
4. Packets coming from F should go out via xx1
Also I try from inside to forward packets without default gateway using
via
A or B with the commands
Ipfw add fwd A all from G to any xmit (or via) xx0
and it didn't work, I've compiled my kernel with IPFIREWALL,
IPFIREWALL_FORWARD, and set net.inet.ip.forwarding=1 in sysctl.conf.
Surely
I will try your configuration on Monday, but it seems ipfw fwd nothing do
forwarding. So how to write for reaching the results (1.,2.,3.,4.)?
Regards,
Narek
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 29, 2007 1:49 PM
To: Narek Gharibyan
Subject: Re: Policy - based Routing problem Need help
Narek Gharibyan wrote:
The right drawing is that one below
___ ___
-[ISP-A](A)(C)[xx0 yy0](E)--(G)[NAT]
[ FBSD ][ Windows ](X)-LAN
-[ISP-B](B)(D)[xx1 yy1](F)--(H)[NAT]
~~~ ~~~
We can't use only FreeBSD box, we need also use Windows box, due to our
company's policy. So you suggestion is not an option. I think we need a
different solution.
ok.
now that we have established the exact layout,
what is it exactly that you want to do?
I gather that you want packets that come into D to go out of F
and packets that come in through C should go out via E
this is achieved by:
ipfw add 1 fwd (G) ip from any to G out recv xx0
ipfw add 2 fwd (H) ip from any to H out recv xx1
what else do you wish it to do?
Regards,
Narek
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Policy Based Routing problem help me
Hi all,
I have a firewall/router with FreeBSD 6.2 installed on it. 2 ISP connection
and 2 LAN connections. I need to do a policy-based routing. All I need that
packets coming from one ISP interface return to that interface (incoming
connections' source based routing) and the other hand do a IP based routing
from the LAN (Some packets will goes out via ISP 1 some others via ISP 2
depending on IPs requested). I tried to do that with ipfw fwd but it didn't
work any way (e.g. with ip.forwarding enabled or no). Even I've disabled my
static routes, default gw. Just it do nothing. Sample configs are
ipfw add fwd ISP_gw from ${my lan} to any via ${eif}
ipfw add fwd ISP_gw from ${my lan} to any out via ${eif}
ipfw add fwd ISP_gw from any to any xmit ${eif}
Ipfw add fwd ISP_gw from any to any via ${eif} out
I don't use nat, proxy. Just need to route.
Please help
Regards,
Narek
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy Based Routing problem help me
On Thu, Jul 26, 2007 at 01:26:17AM +0500, Narek Gharibyan wrote:
I have a firewall/router with FreeBSD 6.2 installed on it. 2 ISP connection
and 2 LAN connections. I need to do a policy-based routing. All I need that
packets coming from one ISP interface return to that interface (incoming
connections' source based routing) and the other hand do a IP based routing
from the LAN (Some packets will goes out via ISP 1 some others via ISP 2
depending on IPs requested). I tried to do that with ipfw fwd but it didn't
work any way (e.g. with ip.forwarding enabled or no). Even I've disabled my
static routes, default gw. Just it do nothing. Sample configs are
ipfw add fwd ISP_gw from ${my lan} to any via ${eif}
ipfw add fwd ISP_gw from ${my lan} to any out via ${eif}
ipfw add fwd ISP_gw from any to any xmit ${eif}
Ipfw add fwd ISP_gw from any to any via ${eif} out
I don't use nat, proxy. Just need to route.
Have you compiled your kernel with the following options?
| options IPFIREWALL_FORWARD
| options IPFIREWALL_FORWARD_EXTENDED
I found that this kind of forwarding silently failed until I enabled the
EXTENDED option in addition to the typical option.
`man ipfw' briefly mentions these two kernel options in the fwd section.
--
Chris Cowart
Lead Systems Administrator
Network Infrastructure Services, RSSP-IT
UC Berkeley
signature.asc
Description: Digital signature
password againg and other policy enforcement
I have some question about password policy in FreeBSD: 1. Administrator can enforce password expire in /etc/login.conf Is there any tool that can check when the password will expire for the users? 2. Any good way to enforce minimum password length and other restriction(like password need at least 2 numbers, 2 special char)? 3. Any ways to prevent user reuse old password? Regards Patrick Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password againg and other policy enforcement
Patrick Dung wrote: I have some question about password policy in FreeBSD: 1. Administrator can enforce password expire in /etc/login.conf Is there any tool that can check when the password will expire for the users? 2. Any good way to enforce minimum password length and other restriction(like password need at least 2 numbers, 2 special char)? 3. Any ways to prevent user reuse old password? Regards Patrick These options have been moved to PAM (Pluggable Authentication Modules). Have a look at /etc/pam.d You will find a file called passwd Edit it and uncomment the line: passwordrequisite pam_passwdqc.so Change the options you require per the manual page (man 8 pam_passwdqc) A lot of restrictions can be placed on the password (history, complexity, number of chars / symbols and so on). Manolis ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password againg and other policy enforcement
Thanks for reply. pam_passwdqc has feature to enforce min password length, and the combination. Also it can check the similarity with the current and new password. But tools to check when users password will expire is missing. Also it cannot keep password history (password that the user had used). The user can use password A, then user change to password B and then change back to password A... Regards Patrick --- Manolis Kiagias [EMAIL PROTECTED] wrote: Patrick Dung wrote: I have some question about password policy in FreeBSD: 1. Administrator can enforce password expire in /etc/login.conf Is there any tool that can check when the password will expire for the users? 2. Any good way to enforce minimum password length and other restriction(like password need at least 2 numbers, 2 special char)? 3. Any ways to prevent user reuse old password? Regards Patrick These options have been moved to PAM (Pluggable Authentication Modules). Have a look at /etc/pam.d You will find a file called passwd Edit it and uncomment the line: passwordrequisite pam_passwdqc.so Change the options you require per the manual page (man 8 pam_passwdqc) A lot of restrictions can be placed on the password (history, complexity, number of chars / symbols and so on). Manolis Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password againg and other policy enforcement
Patrick, good day. Sat, Jun 30, 2007 at 10:12:59AM -0700, Patrick Dung wrote: 1. Administrator can enforce password expire in /etc/login.conf In the /etc/master.passwd. login.conf has the fields, but does not implement the functionality, if the manpage is right: = RESERVED CAPABILITIES The following capabilities are reserved for the purposes indicated and may be supported by third-party software. They are not implemented in the base system. Name Type Notes Description ... expireperiod timeTime for expiry allocation. graceexpire timeGrace days for expired account. = But the following fields are working: Is there any tool that can check when the password will expire for the users? Yep, = $ LANG=C date -r `pw showuser username_here | cut -d: -f 6` Tue Jan 20 00:00:00 MSK 2009 $ LANG=C date -r `pw showuser username_here | cut -d: -f 7` Sat Feb 28 00:00:00 MSK 2009 2. Any good way to enforce minimum password length and other restriction(like password need at least 2 numbers, 2 special char)? 3. Any ways to prevent user reuse old password? man pam_passwdqc, search for the 'match' and 'similar'. But for the '3.': user still can change his password to something and immediately bounce back to the old password. The longer password history changes the chain length, but does not solve the problem completely. The complete password history can help, but it is out of the passwdqc's scope: it just checks against the current password. -- Eygene ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: password againg and other policy enforcement
Me again. Forgot to finish the sentence, sorry. Sat, Jun 30, 2007 at 11:59:49PM +0400, Eygene Ryabinkin wrote: 1. Administrator can enforce password expire in /etc/login.conf In the /etc/master.passwd. login.conf has the fields, but does not implement the functionality, if the manpage is right: = RESERVED CAPABILITIES The following capabilities are reserved for the purposes indicated and may be supported by third-party software. They are not implemented in the base system. Name Type Notes Description ... expireperiod timeTime for expiry allocation. graceexpire timeGrace days for expired account. = But the following fields are working: = warnexpire timeAdvance notice for pending account expiry. warnpassword timeAdvance notice for pending password expiry. = So this can provide some warnings to the user when it logs in. -- Eygene ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
CI INVESTMENTS' e-mail policy - Action Taken
The attachment(s) from the following e-mail was removed due to CI Investments' e-mail policy. From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Thu, 15 Mar 2007 23:40:18 -0500 Subject: STATUS The following violations were detected: --- Scan information follows --- Virus Name: [EMAIL PROTECTED] File Attachment: [EMAIL PROTECTED] Attachment Status: deleted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compatibility Between Releases Policy
Jason C. Wells wrote: Where is the policy regarding compatibility between releases documented? I recall reading once upon a time that FreeBSD won't break compatibility for the duration of a major point release. If a third party wrote software for 6.0 it would be perfectly compatible with 6.1, 6.2 and on. The reason I ask is that I am considering the wisdom of running portupgraed with each minor point release. I don't think you can rely on POLA for ports. But for the base system, the developers try to stick to the Principle Of Least Astonishment, in particular across minor version numbers. Chears, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compatibility Between Releases Policy
Erik Norgaard wrote: Jason C. Wells wrote: Where is the policy regarding compatibility between releases documented? I recall reading once upon a time that FreeBSD won't break compatibility for the duration of a major point release. If a third party wrote software for 6.0 it would be perfectly compatible with 6.1, 6.2 and on. The reason I ask is that I am considering the wisdom of running portupgraed with each minor point release. I don't think you can rely on POLA for ports. But for the base system, the developers try to stick to the Principle Of Least Astonishment, in particular across minor version numbers. Chears, Erik Ports astonish me more often than FreeBSD to be sure. If one uses a port that was built on a 6.0 system, can one trust that no bit rot will occur by the time 6.9 rolls around. Will all of FreeBSDs interfaces and features remain backward compatible? While the developer community might employee POLA in this regard, this sure seems like the kind of policy issue that would be written into our release engineering documents. (I couldn't find it.) Thanks, Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compatibility Between Releases Policy
Jason C. Wells wrote: Ports astonish me more often than FreeBSD to be sure. If one uses a port that was built on a 6.0 system, can one trust that no bit rot will occur by the time 6.9 rolls around. Will all of FreeBSDs interfaces and features remain backward compatible? While the developer community might employee POLA in this regard, this sure seems like the kind of policy issue that would be written into our release engineering documents. (I couldn't find it.) Looks like you want to read this: http://www.freebsd.org/portmgr/policies.html POLA is an ideal, it may be necessary to violate POLA for example for security reasons, and you may have system upgrades that will require rebuild of ports too - recently a bug in openssl required a rebuild of world - and I assume any ports built against the base' openssl. I don't understand your concern, if you upgrade the base system wouldn't it be time to check your ports too? If you insist just don't update your ports tree, that should keep it working with the same versions of ports although you may have to rebuild individual ports. I find it easier to adapt continuously to small astonishments :) Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compatibility Between Releases Policy
Jason C. Wells writes: Ports astonish me more often than FreeBSD to be sure. If one uses a port that was built on a 6.0 system, can one trust that no bit rot will occur by the time 6.9 rolls around. If you mean Is it guaranteed a binary built under x.0 will run, even with remapped libraries, under x.9? then the answer is Hell, no. If you mean Will a port that builds sucessfully under both x.0 and x.9 be limited only by changes in the port and not in the OS? then the answer (as I understand it) is Probably. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Compatibility Between Releases Policy
Where is the policy regarding compatibility between releases documented? I recall reading once upon a time that FreeBSD won't break compatibility for the duration of a major point release. If a third party wrote software for 6.0 it would be perfectly compatible with 6.1, 6.2 and on. The reason I ask is that I am considering the wisdom of running portupgraed with each minor point release. Thanks, Jason C. Wells ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
pxeboot(8) NFS code breaks PIX/ASA policy
I'm PXE booting systems using the dhcprelay feature on a PIX 525 running 7.1(2). The TFTP process of retrieval of /tftoboot/pxeboot works fine, however once loaded NFS mount requests to the server fail per the following messages. In my config, all layer 4-7 packet inspection features are turned off. Any ideas why pxeboot would set the destination UDP port number to 0? It should be UDP/111 and UDP/2049, but alas TCPdump on the server shows nothing coming through. My work-around right now is to recompile pxeboot w/o NFS support and use TFTP file retrieval...which...sort of works. TIA, ~BAS -- Sep 05 2006 17:38:15: %PIX-4-54: Invalid transport field for protocol=UDP, from 192.168.129.130/1023 to 192.168.128.40/0 Sep 05 2006 17:38:19: %PIX-4-54: Invalid transport field for protocol=UDP, from 192.168.129.130/1023 to 192.168.128.40/0 According to Cisco: %PIX-4-54: Invalid transport field for protocol=protocol, from src_addr/src_port to dest_addr/dest_port Explanation This message appears when there is an invalid transport number, in which the source or destination port number for a protocol is zero. The protocol field is 6 for TCP and 17 for UDP. --- l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ ...from back in the heady days when helpdesk meant nothing, diskquota meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Ports upgrade policy
This is my supfile: *default host=cvsup1.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_6_0 *default delete use-rel-suffix src-all *default tag=. ports-all doc-all I have been using it like this for years, obviously changing to the latest release tag. I haven't had problem and I'm not having problems, but my question is this: Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? Obviously, it depends, somewhat, on personal choice, but in terms of stablity and correctness which is better? -- Mike Loiterman grantADLER Tel: 630-302-4944 Fax: 773-442-0992 Email: [EMAIL PROTECTED] PGP Key: 0xD1B9D18E ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports upgrade policy
Mike Loiterman wrote: This is my supfile: *default host=cvsup1.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_6_0 *default delete use-rel-suffix src-all *default tag=. ports-all doc-all I have been using it like this for years, obviously changing to the latest release tag. I haven't had problem and I'm not having problems, but my question is this: Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? Hi Mike, It would be nice I guess if ports were tagged like src but they are not. Basically HEAD is all there is vis-a-vis tags. You can specify a specific date however. Duane Obviously, it depends, somewhat, on personal choice, but in terms of stablity and correctness which is better? -- Mike Loiterman grantADLER Tel: 630-302-4944 Fax: 773-442-0992 Email: [EMAIL PROTECTED] PGP Key: 0xD1B9D18E ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports upgrade policy
On Tue, Mar 14, 2006 at 04:18:13AM -0400, Duane Whitty wrote: Mike Loiterman wrote: This is my supfile: *default host=cvsup1.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_6_0 *default delete use-rel-suffix src-all *default tag=. ports-all doc-all I have been using it like this for years, obviously changing to the latest release tag. I haven't had problem and I'm not having problems, but my question is this: Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? Hi Mike, It would be nice I guess if ports were tagged like src but they are not. Basically HEAD is all there is vis-a-vis tags. You can specify a specific date however. Ports *are* tagged for each release, but they are not branched. Duane Obviously, it depends, somewhat, on personal choice, but in terms of stablity and correctness which is better? -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ports upgrade policy
Erik Trulsson mailto:[EMAIL PROTECTED] wrote: On Tue, Mar 14, 2006 at 04:18:13AM -0400, Duane Whitty wrote: Mike Loiterman wrote: This is my supfile: *default host=cvsup1.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_6_0 *default delete use-rel-suffix src-all *default tag=. ports-all doc-all I have been using it like this for years, obviously changing to the latest release tag. I haven't had problem and I'm not having problems, but my question is this: Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? Hi Mike, It would be nice I guess if ports were tagged like src but they are not. Basically HEAD is all there is vis-a-vis tags. You can specify a specific date however. Ports *are* tagged for each release, but they are not branched. Yes, I know, which is why I asked the question...which is better? -- Mike Loiterman grantADLER Tel: 630-302-4944 Fax: 773-442-0992 Email: [EMAIL PROTECTED] PGP Key: 0xD1B9D18E ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports upgrade policy
On 3/14/06, Mike Loiterman [EMAIL PROTECTED] wrote: Erik Trulsson mailto:[EMAIL PROTECTED] wrote: On Tue, Mar 14, 2006 at 04:18:13AM -0400, Duane Whitty wrote: Mike Loiterman wrote: Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? It would be nice I guess if ports were tagged like src but they are not. Basically HEAD is all there is vis-a-vis tags. You can specify a specific date however. Ports *are* tagged for each release, but they are not branched. Yes, I know, which is why I asked the question...which is better? As I understand it, release tagsare static. If you specify a release tag, you get the ports as they were at the time of that release. Ports don't branch with releases, so if you want updated ports, you use tag=. - Bob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ports upgrade policy
On Tue, 14 Mar 2006 08:35:46 -0600, Mike Loiterman [EMAIL PROTECTED] said: Erik Trulsson mailto:[EMAIL PROTECTED] wrote: [snip] Is it advisable to sync my source to RELEASE, but to CURRENT for ports? Typically, I upgade my ports a few days after they get updated so I'm always running the latest version, but would it be better to sync both ports and source to RELEASE? [snip] Ports *are* tagged for each release, but they are not branched. Yes, I know, which is why I asked the question...which is better? Considerations I can think of - (1) Advantage of using -HEAD (-CURRENT): Updates to ports may include security fixes. (2) Disadvantage of using -HEAD (-CURRENT): It is possible, though perhaps not likely, that an updated port would require something your -RELEASE base system lacked. Jud ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy on the list
is it correct / useful / polite to close a thread marking it as [solved] or something like this, or it's just a waste of time / space / ? I think it could be useful, so other people wanting to help don't waste time trying to give further advices, and people needing help in that subject can see that the problem has been solved. I'd like to see a wrap-up post, with '[solved]' in the subject, and including what the working solution actually is; that way, someone searching the mailing list archives can quickly home-in on the solution... And remember, a search of the archives is pretty-much mandatory before you post for help...or sure enough, someone will jump all over you! :-) ~Dan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy on the list
On 12/15/05, Dan O'Connor [EMAIL PROTECTED] wrote: I'd like to see a wrap-up post, with '[solved]' in the subject, and including what the working solution actually is; that way, someone searching the mailing list archives can quickly home-in on the solution... Yes, this is pretty much what I had in mind. And remember, a search of the archives is pretty-much mandatory before you post for help...or sure enough, someone will jump all over you! :-) Sure! ~Dan -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy on the list [solved]
On Wednesday 14 December 2005 18:33, Dan O'Connor wrote: is it correct / useful / polite to close a thread marking it as [solved] or something like this, or it's just a waste of time / space / ? I think it could be useful, so other people wanting to help don't waste time trying to give further advices, and people needing help in that subject can see that the problem has been solved. I'd like to see a wrap-up post, with '[solved]' in the subject, and including what the working solution actually is; that way, someone searching the mailing list archives can quickly home-in on the solution... And remember, a search of the archives is pretty-much mandatory before you post for help...or sure enough, someone will jump all over you! :-) ~Dan Here, Here! What a time-saver this solution will be! KuDo's! Dan and Pietro! lane ~himself more a seeker than a solver ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy on the list
Hi list, just a little question about how to behave on the list(s): is it correct / useful / polite to close a thread marking it as [solved] or something like this, or it's just a waste of time / space / ? I think it could be useful, so other people wanting to help don't waste time trying to give further advices, and people needing help in that subject can see that the problem has been solved. I don't know the official list rule (guess I could go read it) but I like to see a message noting something is solved and some info - a brief summary on how it was solved. I don't think it is a waste of time unless you go on and on with personal details that don't really pertain to the solution. jerry Thanx, -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Policy on the list
Hi list, just a little question about how to behave on the list(s): is it correct / useful / polite to close a thread marking it as [solved] or something like this, or it's just a waste of time / space / ? I think it could be useful, so other people wanting to help don't waste time trying to give further advices, and people needing help in that subject can see that the problem has been solved. Thanx, -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy on the list
On 2005-12-13 13:41, Pietro Cerutti [EMAIL PROTECTED] wrote: Hi list, just a little question about how to behave on the list(s): is it correct / useful / polite to close a thread marking it as [solved] or something like this, or it's just a waste of time / space / ? I think it could be useful, so other people wanting to help don't waste time trying to give further advices, and people needing help in that subject can see that the problem has been solved. It's nice, IMHO. Exactly for the reasons you describe. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW policy routing...
Hi, I'm trying to move from Linux to FreeBSD, but the most difficult part in this change it seems to be the transition from iproute2 to ipfw to make policy routing, this case works on Linux but I'm still not able to get it works on FreeBSD. Net1: 192.168.0.0/25 Net2: 192.168.0.128/25 Default GW: 69.x.x.193 (ISP1) Alternate GW: 69.x.x.203 (ISP2) NAT Address to use with Net1: 200.X.X.35 NAT Address to use with Net2: 201.X.X.35 | Packet1 from 192.168.0.0/25 | Packet2 from 192.168.0.128/25 __|__ em1: 192.168.0.1 | | | | |_| | em0: 69.x.x.194 __ | Packet1 | | Packet2 200.x.x.35 | | 201.x.x.35 __ |____ | __ | | | | |69.x.x.193| |69.x.x.203| |_| |_| | | | | ISP1ISP2 So, when the packet 1 reaches the default gw, was modified by NAT in my FreeBSD box, getting the src address of 200.x.x.35, and when the packet 2 reaches the alternate gw (69.x.x.203), it was also modified by NAT with the src address 201.x.x.35, that's working ok, but the redirection fails, here's my ipfw configuration, where all is allowed by default. natd -a 200.x.x.35 -p 8668 natd -a 201.x.x.35 -p 8669 ipfw add 30 divert 8668 all from any to 200.x.x.35 in recv em0 ipfw add 30 divert 8668 all from 192.168.0.0/25 to any out xmit em0 ipfw add 40 divert 8669 all from any to 201.x.x.35 in recv em0 ipfw add 40 divert 8669 all from 192.168.0.128/25 to any out xmit em0 ipfw add 50 fwd 69.x.x.203 all from 192.168.0.128/25 to any I have tried changing the last line for, but the results were the same: ipfw add 50 fwd 69.x.x.203 all from 192.168.0.128/25 to any in recv em1 ipfw add 50 fwd 69.x.x.203 all from 201.x.x.35 to any I have read about policy routing and it seems that everything is in order, but still doesn't work.Please help! -- Este mensaje ha sido analizado por el antivirus de ESPOLTEL S.A. en busca de virus y otros contenidos peligrosos, y se considera que está limpio. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tripwire Policy File and 5.4
Hi, I'm not so convinced of that - after a cvsup of ports overnight, this remains: # ll /usr/ports/security/tripwire/files/twpol.txt -rw-r--r-- 1 root wheel 20651 Mar 5 2002 /usr/ports/security/tripwire/fi les/twpol.txt Well, just to prove me wrong I updated ports again and: # ll /usr/ports/security/tripwire/files/twpol.txt -rw-r--r-- 1 root wheel 20891 Aug 10 17:46 /usr/ports/security/tripwire/files/twpol.txt I've updated, but unfortunately my two main complaints - that of not being about to package it, and no interactive updates - remain. cheers, -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tripwire Policy File and 5.4
FYI- The policy file looks to be updated for 5.x systems now. Tripwire's back. Bret Bret Walker wrote: Does anyone know where I can find a good Tripwire policy file for 5.4? I installed tripwire-2.3.1.2_3 from ports, but the default policy file throws a lot of errors. I think it's tailored to 4.x. Thanks, Bret -- Bret Walker Technical Support Consultant Medill School of Journalism Northwestern University 847-467-7845 847-491-2370 fax [EMAIL PROTECTED] http://www.it.medill.northwestern.edu/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Tripwire Policy File and 5.4
The policy file looks to be updated for 5.x systems now. Tripwire's back. I'm not so convinced of that - after a cvsup of ports overnight, this remains: # ll /usr/ports/security/tripwire/files/twpol.txt -rw-r--r-- 1 root wheel 20651 Mar 5 2002 /usr/ports/security/tripwire/files/twpol.txt Last time I tried, Tripwire was still unable to perform an interactive update, which is no great inconvenience but doesn't really inspire confidence. The only improvement I've noticed since the first 5.x is that it at least compiles now - given the lack of effective replacements for Tripwire this is the least we could expect. Not being able to package this port has been a real trial, however, and I don't believe that it wouldn't be possible with a bit of consideration - no, I'm not volunteering right now as more important things are pressing me. I have adapted my own policy/config file and periodic script to run with output in the daily security email - I'm happy to post these if anyone is interested. cheers, joel -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Tripwire Policy File and 5.4
Does anyone know where I can find a good Tripwire policy file for 5.4? I installed tripwire-2.3.1.2_3 from ports, but the default policy file throws a lot of errors. I think it's tailored to 4.x. Thanks, Bret smime.p7s Description: S/MIME Cryptographic Signature
Policy Violation
The following message sent by this account has violated system policy: From: freebsd-questions@freebsd.org To: [EMAIL PROTECTED] Date: Wed, 18 May 2005 10:17:10 +0200 Subject: unknown The following violations were detected: --- Scan information follows --- Virus Name: [EMAIL PROTECTED] File Attachment: textfile.zip Attachment Status: deleted --- File name Block information follows --- File Attachment: M2005051810171009874.mes/textfile.zip Matching file name: * Textfile.zip ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Policy Violation
The following message sent by this account has violated system policy: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 16 Jun 2004 09:29:51 +0200 Subject: warning The following violations were detected: --- Scan information follows --- Virus Name: [EMAIL PROTECTED] File Attachment: nomoney.zip Attachment Status: deleted --- Subject Block information follows --- Subject: warning Matching Subject: warning ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Policy-based transparent proxying
Hi guys Suppose my FreeBSD machine is a router/firewall for a small private network and I use transparent proxying. ipnat.conf looks like this : rdr fxp0 192.168.0.254/32 port 80 - 192.168.0.254 port 8000 tcp rdr fxp0 0/0 port 80 - 192.168.0.254 port 3128 tcp map dc0 192.168.0.0/24 - x.x.x.x/32 proxy port ftp ftp/tcp map dc0 192.168.0.0/24 - x.x.x.x/32 portmap tcp/udp auto map dc0 192.168.0.0/24 - x.x.x.x/32 fxp0 being the internal iface and dc0 the external one Now suppose I shall have one more subnet - 192.168.1.0/24 and I want to nat it to another external IP address and make it use a different proxy. With nat it's rather clear but as to using a separate proxy - man 5 ipnat and practice says I can't use from clause in rdr. Any ideas (except switching to ipfw) ? Thanks all for your attention Igor ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy filtering with postfix
On Sun, 2004-05-30 at 13:55, Robert Storey wrote: I'm not an expert on Postfix or any other MTA, but it might be that your logs are displaying headers or attachments with high-order ASCII text used by non-Roman scripts (Chinese, Korean and Japanese would be good examples). I have some files from Chinese Windows (Word docs and html) and when I list the filesnames at the console in FreeBSD, this is how they display: .doc .htm 1?1.doc ??.doc ??? .doc ? ??.doc ?? ?.doc ??.htm .doc ??.doc ??? ?.doc ??? ??.doc ???.doc ?.doc ??.doc .doc So maybe this is your problem. best regards, Robert On Sun, 30 May 2004 01:43:54 +0300 Lefteris Tsintjelis [EMAIL PROTECTED] wrote: Hi, I am trying to setup policy but I keep on getting all these in my log files. postfix/policy-spf[15755]: : testing: stripped [EMAIL PROTECTED], stripped [EMAIL PROTECTED] postfix/policy-spf[15755]: : SPF : smtp_comment= , header_comment=?? ?? postfix/policy-spf[15755]: decided action=DUNNO Are all these normal to show up in the maillog? Anyone has any idea what they are? I suspect it maybe an IPv6 problem. Can anyone please confirm it? Thank you, Lefteris If you are using the header_check options in postfix the following rule -8-- # This filter will block subjects that contain ISO specifications. # If you use any languages other than English, # you might need to comment this out. /^Subject: .*\=\?ISO/ DISCARD ISO header -8-- will discard emails that use other languages. This could be what you are looking for if you need to manage content that is in non-english character sets. You could look for the iso header then sort/discard accordingly -- Murray Taylor Special Projects Engineer - Bytecraft Systems Entertainment P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 M: +61 417 319 256 E: [EMAIL PROTECTED] or visit us on the web http://www.bytecraftsystems.com http://www.bytecraftentertainment.com This Email has been scanned for Viruses by MailMarshal. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Policy filtering with postfix
Hi, I am trying to setup policy but I keep on getting all these in my log files. postfix/policy-spf[15755]: : testing: stripped [EMAIL PROTECTED], stripped [EMAIL PROTECTED] postfix/policy-spf[15755]: : SPF : smtp_comment=, header_comment= postfix/policy-spf[15755]: decided action=DUNNO Are all these normal to show up in the maillog? Anyone has any idea what they are? I suspect it maybe an IPv6 problem. Can anyone please confirm it? Thank you, Lefteris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Policy filtering with postfix
I'm not an expert on Postfix or any other MTA, but it might be that your logs are displaying headers or attachments with high-order ASCII text used by non-Roman scripts (Chinese, Korean and Japanese would be good examples). I have some files from Chinese Windows (Word docs and html) and when I list the filesnames at the console in FreeBSD, this is how they display: .doc .htm 1?1.doc ??.doc ??? .doc ? ??.doc ?? ?.doc ??.htm .doc ??.doc ??? ?.doc ??? ??.doc ???.doc ?.doc ??.doc .doc So maybe this is your problem. best regards, Robert On Sun, 30 May 2004 01:43:54 +0300 Lefteris Tsintjelis [EMAIL PROTECTED] wrote: Hi, I am trying to setup policy but I keep on getting all these in my log files. postfix/policy-spf[15755]: : testing: stripped [EMAIL PROTECTED], stripped [EMAIL PROTECTED] postfix/policy-spf[15755]: : SPF : smtp_comment= , header_comment=?? ?? postfix/policy-spf[15755]: decided action=DUNNO Are all these normal to show up in the maillog? Anyone has any idea what they are? I suspect it maybe an IPv6 problem. Can anyone please confirm it? Thank you, Lefteris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Internal Policy Routing
Hello, i 'am search for an solution for a multi-jailed enviroment. I have an system with around 20 jailed enviroments that are made for easy of use. The idea is to add to this jailed system an jailed central firewall for all other jailed enviroments. To gets this to run i need a special routing which is easily done on linux with policy routing but i didn't found a similar function on bsd. My network layout look like this, remember this network is running in one box. internet---firewalljail(69.10.3.3) | internaljail-0(192.168.19.1) | internaljail-1(192.168.19.2) | internaljail-2(192.168.19.3) | internaljail-3(192.168.19.4) To enable this i need to add to the internaljails an defaultroute to the 69.10.3.3 and the 69.10.3.3 needs an defaultroute to the internet so that the firewalljail will transfer(filter) all packets which are send/received from the internaljails. Is there any solution. I know that there some additional problems with setting the ipf/bpf kernel infos from an jail but this problem is solveable, first solution is not use an jail for the firewall, to use the master. Thanks in advance Meno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Tripwire Policy File
Hello, I'm trying to build a solid tripwire policy file. So far I have only found one resource to use: http://www.schlacter.net/public/FreeBSD-STABLE_and_IPFILTER.html Though this seems to be a good one it is written for 4.6. I'm not sure if this is a problem or not. So my questions are: How much changed (file structurally) in 4.8, is this 4.6 o.k. to use? Also if anyone else knows of any other resources to help me build this that would be great. -Stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
