[LARTC] Quick Question...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Are there plans to implement the anycast feature set in ip for IPv6 anycast addresses? Thanks in advance, Stuart Sheldon ACT USA - -- Spider Pig, Spider Pig, Does whatever a Spider Pig does. Can he swing, from a web, no he can't, he's a pig. Look Oot! He is a Spider Pig -- Matt Groening - "Spider Pig Lyrics" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNzW3rAAoJEFKVLITDJSGS6OAQAKZKy4GBTOQRE2dVioYN8DSP 4EfnbtfHPMMXrUkuZXVerJd2b2B5ycXFOdINTZE40YkUyPoYvOEJawg7G3zmh53T rmJSUxJM9GblJy/SU6Z4+hE2OgyaZb4yyMD6JdoHiJSnnTyznTj4czMO+tFiLX9i v53zwBxGLk38jnGxfdrv7RoxJOdAorlKfE+GpYX47VUbpbbOWijT0mgoHTrmVR8E VvkyyOZiLKkJv40qonk3M+yuDVO3Hl3y1KDxQjr/A7vONIAYyAS88/RA72hUgwZQ 630nLSpgzC8BJGIB9vMBPeqS+SZT6OO5L34yR8+wNYfqwy5n+we7EgcGo6qwW9p7 f9btoCbCGIuv6pKS4snpK1eqJtl9gDGbOVRh3dtgxjP28oljGKweIfINhnO+2abJ NLo5upOPUGj2yoOpUDNHrxO2Z+1l0Hvh/DujaBJIFh2tT9rNtlYJysT9LK7G+LYv edY+nkfFDJf3KCQJ9a+UAuc9OjYO8uFTWCjRsqH5aK+nykNj22waiMjRDGFDNEml q2fvtJ1Xeo2mR5RsGonAYnWdiMvLONBoRsk4/5OFuXJqeI+UkMtmT+Ku8gSKbbCW rxHanCbJNVysEldGf1Wzk3V9DEf4xEyzgKaB07Uu5pvjHkEcqDKqsGoZcOJ71fib v7VaIhcMBdq6VSSAN7e3 =QSk7 -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] List fault?
Hi, has anyone contacted vger.kernel.org about lartc list creation? Andrew Burgess wrote: On 05/04/2011 07:10:01 PM, Russell Stuart wrote: A list on vger.kernel.org does seem like a workable solution. Large a third party provider such as google groups, yahoo groups, github, sourceforge or savanaha may be an even better solution as they would be just a reliable, and they provide a web page were we could collaborate on for things like HOWTO's. kernel.org hosts wikis (and bugzilla) too. seems like a good choice to me. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: List fault?
On Thu, 2011-05-05 at 00:12 +0200, Michelle Konzack wrote: > Hello Grant Taylor, > > Am 2011-05-04 14:24:17, hacktest Du folgendes herunter: > > On 05/04/11 13:37, Radu Oprisan wrote: > > >I will try to contact LARTC in order to ask them for permission to > > >take over this one. > > > > (I'll make this pitch again.) > > > > Does any one have any objections to (re)configuring the mailing list > > so that it sets the Reply-To header so that replies are directed > > back to the mailing list (as a discussion list)? > > For WHAT? Real MTAs have byside and > > > All in favor? > > Any one against? > > Yes. Sorry guys, but I have to support Michelle here and refrain that anyone not familiar with the "Reply-To" problem in the context of mailinglists do a quick google on "Reply To munging". It's really just some ugly workaround for old/broken MUA to set Reply-To for a mailinglist pointing back to itself. Please don't! -- Best regards, Kilian ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] List fault?
Hi I sort of agree. This list just magically came back to life. Why? Did someone flip a switch? Who is that person? Will they turn it off again? Also, regarding the site, its very static. I think a wiki could replace it and breath some new life into it. Adrian 2011/5/5 João Almeida : > I just ask again, who is in charge now? > Why is the list awake again? > Not that I'm against a new list, but I propose four things: > 1- Know what is going on! > 2- Maintain this list for "compatibility" purposes > 3- We can create a new one with a more easy address but keep them "tied > together" at least for a while > 4- Who is in charge of the web page? I myself would like to add some life to > it... A repo of howtos/confs/scripts would be very nice, IMHO... > Basically, I agree with the new life of the community but why not revamp the > existing one? Lists can be relocated, servers as well... > What is the point of loosing all the work done so far? > Best regards, > João Almeida > On Thu, May 5, 2011 at 2:52 PM, Andrew Burgess wrote: >> >> On 05/04/2011 07:10:01 PM, Russell Stuart wrote: >> >>> A list on vger.kernel.org does seem like a workable solution. Large a >>> third party provider such as google groups, yahoo groups, github, >>> sourceforge or savanaha may be an even better solution as they would be >>> just a reliable, and they provide a web page were we could collaborate >>> on for things like HOWTO's. >> >> kernel.org hosts wikis (and bugzilla) too. >> seems like a good choice to me. >> ___ >> LARTC mailing list >> LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Moving the LARTC list to a new domain.
/If/ this mailing list is to move to a new domain, I'd suggest that we move it to something at lartc.org if at all possible. Rather than moving it to a different domain that is not directly associated with LARTC or portable. Doing that would keep the mailing list address (hopefully la...@lartc.org) dis-associated with any other entity and would allow it to move from location to location as the need arises over the coming years. Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] SMB traffic routing/blocking...
On 05/04/11 17:11, Don Gould wrote: Sorry, my bad. No problem. We are all human. I want to block, drop, what ever, Microsoft networking... wins? but I do want to permit internet networking (for what of some better terms. Ok. So we are only talking about filtering TCP / UDP ports 137, 138, 139 and 445. (Isn't M$ networking fun...) I don't want users on the 2.0 network to see the 'shares' on the 3.0 networks in 'network neighbourhood'. I think I know what you are after. I know this could be achieved by simply putting everyone in different work groups rather than the default of 'workgroup' (or 'home' depending on what version of windows you're using). But I don't control the computers, so I can't do that. Now we are getting in to some M$ networking issues. I think the proper term (as I (mis)understand it) that you are after is "browse". Just because the computers are in a different workgroup does not mean that they won't be able to see each other. In fact, workgroups mean little any more. If any thing, the "workgroup" is sort of (very rough analogy) like your local subnet in that it takes marginally more effort to go out side of it, but still very possible to do. - In short, using different workgroups would not suffice for what you are wanting. If user 2.35 sets up WAMP on their PC, I do want 3.45 to be able to see that. http://192.168.2.35/ ... blar :) *nod* TCP / UDP ports 137, 138, 139 and 445 What I want is... When a user browses the "network" (windows term), I want them to see DonsNAS\192.168.x.0_Share That's where I eventually want to end up. Heh. Now more M$ networking fun. I think you are about to run in to the network visibility vs accessibility issue. Specifically, if you want computers to be able to "browse" the network (neighborhood) and find computers to access, you are going to have to have a functional browse master list. Complicating this is the fact that you have multiple networks (subnets) trying to tie together. In the end I think you are going to end up with a single unified browse maser list that all the computers are on. Now, that does not mean that the computers will be accessible, just that they are on a list. Everyone on the x.0/24 network gets access to 1.xGb of shared space where they can put stuff they want to share with everyone else on their network. People on y.0/24 will have their share on the same NAS (which is actually a nice Debian box running samaba). The share is to be fully open to everyone in x.0 but not visible to people in y.0 etc. Ok. So you are exploiting some of Samba's features as a central file server. Think in terms of a block of apartments where each apartment is getting a x.0/24. I'm wanting to give all the users in apartment 1 a network and some shared space so they can transfer files etc but I don't want the people in apartment 2 seeing the files of apartment 1. However I don't have control of the computers, so I can't do stuff like ACLs etc. Heh. Isn't multi-tenancy networking fun? I don't want them to be able to 'browse the network', errr... I don't want them to be able to "browse" the other networks. Here "browse" can mean multiple things: 1) see the computers on a list that are connected to the network and 2) access a given computer and see the contents there on. I think you are going to have to live with #1 and use IPTables to control #2 via firewalling. Ya, that's not what I want. I only want to drop the smb traffic. Is that port 137? or do I need to drop more than that? To be save, I drop both TCP and UDP for ports 137, 138, 139 and 445. (We actually only need to block a subset of those ports, but I don't bother to remember exactly what is needed and just block those 8 ports and have been fine for the past decade.) If I do what you just said then skype between networks will break won't it? or it will travel out the public IP and transit to another peer? As I broadly said it, yes. However, if we refine it to be for the 8 ports in question, no. Question: Do you want to control the 2., 3. and 4. network's access to the the 1. network so that they can only get to the servers IP, or can they access the entire 1. network? At this point, I think your firewall rules will be such that you first allow SMB/CIFS traffic (from any network) to the 1. network -and- from the 1. network (to any network). and then you drop / reject any other SMB/CIFS traffic. (You may want to refine "1. network" to be "the NAS server's IP".) Thanks for the help man :) You are welcome. Grant. . . . P.S. For the record, you really are crossing two completely different network layers. One is the TCP/IP & routing layer and the other is the M$ Windows Networking layer. Doing this can be interesting (and I don't mean in a good way), somewhat difficult, and sometimes prone to compromise (as in I don't like it but it works, not the security breach) and failure. ___
