Messages

1

Installation issues / Re: dazuko possible?

« on: September 21, 2009, 07:39:44 pm »

Hi,

Well, I've only seen 1 virus come into my wife's machine via email.

It was on either 8.10 or 9.04.

Klam reported it immediately.

At one time I thought Clam/Klam was forensic only until this happened.

Am I missing something re: what "on the fly" is suppose to be.

Yes.

I'm paraphrasing ... there are only a few ways for 'bad things' to hit your computer. Certain well defined ways, such as web browsing, or e-mail, have settings wherein clamav gets a peek at it before it actually lands on your FILE SYSTEM. There are many ways in which a bad thing can hit your file system - you could write a file with some app that does so, or you may put, or have put, a bad thing on your file system, a file system you use on another's machine, or they on yours.

Normally, unless you tell clamav to check your system, you'll never know when this last happens. So, clamav has a facility to schedule scans. (Problem is, when something is detected, well, it's already there. The damage has been done.)

On the fly interacts with the file system so that clamav gets a peek at it before anything lands from anywhere.

But clamav does not, and can not, do so by itself. Dazuko (compatibility?) is a kernel module that exposes an interface wherein things are allowed to have a peek before a file, from wherever, by whomever, actually gets to the disk. Clamav can take advantage of such a facility, but not until that facility is made available to it.

Here's a way to test ... turn off clamav web protection long enough to get the standard test virus (who's name and location escapes me at the moment), onto your system. [You can turn the web protection back on.] Now copy that file, anywhere, even to a different name in the same directory. It should not be able to land - if it can't, you have on the fly protection going. [In fact, you shouldn't be able to get the file in the first place - you only turned off web protection, not on the fly detection.]

If it lands, you are essentially unprotected. Until you run your next scan. And by then the damage has been done. (Suppose it only damages a little bit of a file ... how will you know what to fix?)

Now ... suppose it takes several days to complete a system scan ...
- how many bad things could have landed in the meantime?

2

Installation issues / Re: dazuko possible?

« on: September 21, 2009, 05:14:15 pm »

I think (not 100% sure - been a while and getting old) I installed Clam back in Dapper with no problems via add software GUI.

Been through all the upgrades to 9.04 without having to compile.

I can say that I've installed ClamAV using apt-get without any recompile, if that helps...

Please note, and be sure ... I am talking about on the fly scanning.

Definitely, for as long as I can remember, I've been able to install klamav (clamav) via the repository. I have never been able to enable the on the fly live scanning aspect of it, however, with only that, and no further or additional effort.

So, please, confirm you have added on the fly, real time, scanning.

3

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 25, 2009, 04:00:51 am »

... then I suspect that LinuxMCE is not the product for you. Try MythTV, VDR or XBMC...

I'm not sure I agree with that. Here's why / my perspective ...

Asterisk/MythTV (etc.) is my initial goal, but given convergence, I don't think it is my / the end goal. From what I've seen, lmce is, or will be, the end goal. It's just that home control is not the first priority in my set of goals.

I'd rather go through the learning curve, once, with lmce, than twice - via Myth then lmce. I know I'm going to go through some pain, as I ignore or neuter some aspects of lmce, and have to work with / through others (dhcp, firewall), but I believe it will be worth it in the end.

But that's just me. Certainly this is not the first time I've heard that if all you want is an Asterisk/Myth box, then the learning curve of lmce may be more than you want.

But look, lmce opens up with "Tell me what you rooms are." ... imagine the possibilities.

_That's_ a perspective / approach _I_ want to be part of. It just makes so much sense.

YMMV.

4

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 25, 2009, 03:50:02 am »

Not sure I follow the "not wanting NAT" bit... personally I do want NAT, but perhaps you meant something else?

Agreed, you want NAT between your internal and public networks. But the network layout described in this thread is an openwrt / dd-wrt router connecting public and internal networks (and doing NAT), and multiple internal devices behind it. I have seen nothing to believe that the non-core computers present are behind and not beside the core. Yes, NAT is needed, but not on the core in this thread.

I have no idea what does the QoS, but I believed it was the firewall (certainly I have read in the past that disabling the firewall disables the QoS)...

Agreed, it's what I've been reading, but I don't understand why, to date. Part of the question I posed in my last then, is really "Is firewall a misnomer - turning on the lmce firewall is accomplishing more than what one at first blush expects a firewall to be doing?"

The firewall being more than a firewall is not intuitive as only firewall rules are specified under that tab. I can certainly see how nat / routing / firewall are all involved here in this thread, and how it is not one stop shopping in webadmin under firewall. And I can see how wanting to do anything different in webadmin to manage it would be a can of worms to open, without some serious reason to do so such that it would rise to the top of the priority list. [We may get there, but not today.]

If we assume that (TBC), then you need to understand that there is much more to QoS than "flags". Broadly the 2 halves of QoS are, "marking" and "enforcement"...

Thank you for your post - it reminds me / us that not only must the source app (or, given that the firewall enables / disables QoS, source machine) set the flags, all the points of network concentration (e.g. switch, router) between must honour those flags.

For brevity (because this gets long very quickly) ... you are assuming (in this thread) that all machines are behind the core, and that the core is doing the routing. The former may or may not be true, the latter is explicitly not true. Again, in this thread.

Whether or not the firewall is turned on, the flags should be honoured by the core (routing) [and the flags should be set by the app] - or the firewall is more than a firewall. (The question of which, is what started this branch of the thread.)

I'd guess that that is the cause of much forum traffic - many saying don't turn off the firewall as you'll lose functionality that is sort of the whole point of having lmce in the first place, and others saying 'I already have a firewall.' And I'd suspect made worse, when coming from a Kubuntu install up via CD, as such users would be more aware / sensitive to such fine points. Vs. black box DVD fire-and-forget installs.

Like I say above, I'm not sure another approach (within webadmin) is appropriate, given the complexity and inter-relationship of the concepts, but certainly it should be kept in mind should those areas see further work.

In the meantime, perhaps some relabelling of the 'firewall' tab may be warranted, and an explanatory note that more than a firewall is covered under it.

For myself, I'd like to see the current iptables listed in text under the new rule entry boxes, but I'll put that request in when I get back to that area. (Other things happening around me at the moment.) Certainly doing so would reveal that much more than just what we think of as firewall rules are being turned on/off with the firewall tickbox.

5

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 25, 2009, 01:24:52 am »

Which brings us back to a well reasoned earlier post - if the lmce firewall is doing no harm, why not leave it on / alone? (DHCP no longer in the picture, as it's being left on, here.)

That is workable, just be aware that turning off the firewall means you loose the QoS features for VoIP and NATing to the internal network, but that may not concern you.

Now that's interesting. I get the not wanting NAT in this situation. But the quote implies that either lmce firewall != iptables, or iptables (as used by the lmce firewall) is more than just a firewall. It implies it's doing some packet massaging too. No?

If the routers (ddwrt), switches (?), NICs, and so on and so forth are all QoS aware, why would the lmce firewall matter? Unless it, and not Asterisk, is the beastie flipping those flags on in the packets?

6

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 24, 2009, 07:31:54 pm »

So would it work to do as Oatz said in his first post and disable linuxmce's firewall and use the gateway before its firewall? And also having to re-edit the dhcpd.conf on reboots.

I am not a LinuxMCE expert. My best guess is:
- turning off the LinuxMCE firewall exposes you to the big bad world. If you have another firewall in place before the LinuxMCE machine, then the big bad world isn't getting to it, so you should have no additional issues beyond what you already have.
- my sense is that dhcpd.conf is re-written at each detection of new device, not at restart. So that's the point at which you would reschmuck dhcpd.conf. I also sense that you could just turn off LinuxMCE's DHCP and use another, _but_ LinuxMCE would lose the ability to detect new devices - you would have to manually add them on your own. Not just to your network / dhcp, but to LinuxMCE as well.
  - if you are not using lmce for home control / mobile orbiters, this may not be a big issue. In that situation, you are not frequently adding / (re)moving devices. If you are moving about from room to room with your orbiter (bluetooth / wi-fi device, cell) then dhcp is how lmce tracks what's where, to control what. e.g. If you wander about from room to room and use an orbiter to change the tv channel, you want it changing the channel in the room that you are currently in, not the room that you were just in.

You are defeating the intent of lmce in doing these things. If the functionality lost in doing so is not of concern to you, then you're still good to go. IIRC.

7

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 07:30:21 pm »

While the setup that I plan to have is not standard ...

Cool! Thank you for the post! Including the product heads up. Mind you, switches _under_ the house is not something that immediately occurred to me to plan for. (-:

8

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 06:52:23 pm »

If lmce is a black box home control system, it is also a computer. As such it must peacefully and instantly co-exist with the computers already in the home. Since it does not, people must 'break their systems.' Or, people must double-device and double-DSL their homes, which they find unacceptable.

some see LinuxMCE as complete solution/appliance.. so that "must" is also a point of view :-)
br, Hari

Absolutely.

But I suspect such are quite significantly in the minority. If these forums, etc. are in any way representative of your audience, then I think this is born out. Granted - common thinking says only a very small percentage of the whole even participates in such. But that thinking also seems to agree, in my impression, that those being vocal are the thin end of some wedge.

9

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 06:49:18 am »

What I mean by that is that when my kids comes over and plug their laptops in or connect to the wireless, LinuxMCE would give me the 'found new shit'.  With my PC network and LinuxMCE network separate, my Core will only detect hardware I intentionally want to connect to LinuxMCE.

Isn't this what the 2nd DHCP range is for?

Or could you avoid this problem by assigning IPs to mac addresses? (This is done by entering device IP addresses for each device, accomplishing, essentially, static DHCP addresses?)

Hey, if non-DHCP addresses are placed in the device entry, does this not inherently segregate out non-designated lmce devices by virtue of them being within the DHCP range? Do out of range / static IP-Mac dhcpd.conf entries get made?

And can someone explain ... if I have two ranges specified, say 1-100 and 101-200,  where does a newly receiving DHCP device land?

10

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 06:40:35 am »

Unsolicited - you have all the advice you need. The consensus is basically unanimous. If you still want to set it up another way, then do so, but there is zero point continuing to argue the point in this or other threads. To do so would likely be considered trolling.

I'm confused. I no longer even remember what started this thread, but it has meandered into all sorts of interesting discussions.

Looking back, it's not even my thread, as far as I can tell. So I'm not sure why I'm being singled out.

In this DHCP thread, if I was seeking an answer, my answer was received long ago - you will have to re-write dhcpd.conf occasionally. (Since then, these other interesting discussions have occurred.)

I'm not sure which consensus you're talking about - there have been 3 or 4 community / forum recognized solutions to DHCP use presented herein.

I certainly don't intend to be trolling. I don't think I've been arguing. But I'm happy to be shown the error of my ways.

11

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 06:25:22 am »

I like ice-cream.

*nod head*

Ah, but what flavour?!?

12

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 06:22:47 am »

You guys are needlessly complicating your setups.

Why? WHY?!?!

If you do some hard thinking about why, you can probably answer the question yourself. But don't put out that effort if you're not willing to consider the answers as valid. [That is NOT a shot.]

Reasonable people generally do reasonable things. One of the reasons you have to keep asking 'Why?' is because what's reasonable depends upon you're perspective / where you're coming from. Perhaps the perspectives boil down to a perspective of "What we have." or "What we're offering." vs. one of "What we want." It gets further complicated with elements of not knowing we wanted it but got it, and having got it, why do we not also have something else.

    I'm trying to think of a couple of examples. Perhaps these will do ... (1) People got text messaging on their phones - it was a new, and now de rigeur, thing. It didn't take too long until people started saying what do you mean only 168 (or whatever) characters at a time! (2) [Ontario, Canada] Phones have been coming with bluetooth. Why the heck can't I buy one with wi-fi from my carriers! (Different answer for that, because carriers can't collect data charges when you go over wi-fi, but the principle, given X logically wanting Y, is the same.)

If lmce is a black box home control system, it is also a computer. As such it must peacefully and instantly co-exist with the computers already in the home. Since it does not, people must 'break their systems.' Or, people must double-device and double-DSL their homes, which they find unacceptable.

I suspect things ultimately boil down to a learning curve / non-zero time to a finished integral installation / home network. And that's a constantly moving target in our dynamic world - so I don't think 'why?' is going to be solved any time soon. Merely which particular thing they're breaking that day.

After all, things must go through a beta / testing stage. It doesn't just spring into being in instant perfection.

Everyone is just going to have to deal.

That being said, someone simply asking 'Why?', as in "You people are idiots.", is not productive or conducive. People only break their systems (as in, work outside the box) to accomplish required, at least to them, functionality. If that required functionality were already present, they wouldn't be 'breaking' their systems.

I do get your perspective though - frustration, and, there are only so many hours in a day. And, as I say above, perfect results don't spring out of thin air.

13

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 18, 2009, 05:40:17 am »

i like vlans

*shake head*

Now THERE'S a good thought!

Put all the 'good' / home / permanent stuff on the non-default vlan. Then when new, temporary stuff comes in, it ends up on Default. And you can set up policies and procedures as to how you want to deal with that.

But ... under the scenario mentioned, kids friend comes over with his laptop ... presumably your child's computer is a media device (he can play video, music, whatever, on it from the media library), and therefore on vlan 1. But the friend's computer would land on vlan 0.

I'm assuming they want to play a death match against each other, or something, via computer. [What the heck do _I_ know about this stuff, I'm guessing here!]

May get tricky defining what traffic can autonomously travel between the two vlans.

14

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 16, 2009, 07:46:21 pm »

... and I don't get any annoying 'found new shit' ...

(-:

I'm not disputing or disagreeing with anything you say, but the intent of the first post in the thread was to attempt to work within the framework of the design of LinuxMCE. As we are so often told to do. And, theoretically, if not in practice, once the core is built, it's built. (Not in practice in the sense that functionality is evolving, not static.)

If I understand correctly, could you not accomplish the same functionality you mention by turning off the firewall and DHCP in the core? (Everything being on the same network.)

15

Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!

« on: April 16, 2009, 07:14:29 pm »

I'm new to LinuxMCE, but not new to networking.  Why not setup another subnet for LinuxMCE?  ...

Every device in the house has some level of media capability. Or the point of presence for a bluetooth dongle, and so on and so forth. A second network would mean duplicating devices.