[lcdproc] LCDproc still alive? Yes :)

[William W. Ferrell]

--R+My9LyyhiUvIEro
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Matt (madmatt@bits.bris.ac.uk)'s mailer blew these chunks:
> William W. Ferrell wrote:
>=20
> | * Matt (madmatt@bits.bris.ac.uk)'s mailer blew these chunks:
> |=20
> | Actually MtxOrb sent me a display about a year ago to mess around with.
> | Because Real Life(tm) got in the way, nothing came from it except for
> | one interesting proof-of-concept (Rob was even surprised to see this
> | work, since he was convinced before I did it that it wouldn't :) ... you
> | can cram a *LOT* of characters on a graphical LCD with a proportional
> | font.=20
>=20
> They could be quite nice, you could start doing 3d graphs, all sorts of
> eye-candy! It'd be a nice extra driver to have...

Yup, lots of eye-candy potential :)

> | Yet another definite necessity, and another motivation for the rewrite.
> | Authentication is the easy part: the server keeps a password (stored in
> | plaintext, unfortunately, but sensible file permissions keep that
> | security risk minimized). When a client connects, the server generates
> | and sends to the client a random string, then generates an MD5 hash of
> | the password concatenated with that string for itself (never transmits
> | this hash). The client combines *its* password with the random string,
> | MD5 hashes it, and sends it to the server. If there's a match, *ding*,
> | you're in. If not, you're told where to go :)
>=20
> Couldn't we just store the MD5 hash in the config file? I've been using
> LIDS for a while now, and they get around the problem by using the admin
> tool to create a RipeMD-160 password that you pop into the kernel config.
>=20
> Surely the client could then just create the MD5 hash and send it across
> the connection?

If only the password is hashed, the hash will never change; anyone
listening or snooping on the network can get the hash, then they've got
the password (they could just send the hash themselves, get
authenticated and allowed in, and then try to exploit stuff).

By sending a random string to the server, and making the client hash
both the password *and* the random string, it's impossible to generate
the proper hash without knowing both the random string and the password.

> Maybe my encryption theory isn't what it used to be...

That's okay, I barely understand this at all :)

> | The server also needs to be built to take a list of allowed and
> | disallowed clients, and not even talk to clients who aren't allowed to
> | connect.
>=20
> Kind of like the /etc/hosts.[deny|allow] file I guess...

Yeah. I had in mind Apache's directives for this kind of stuff.

> | Finally, yes, I'd *love* to implement (optional) encryption. I'm sure
> | for *most* applications 56-bit RSA or DSA (I think I got those right ;)
> | would do; we're sending stats, not passwords, over the network :).
>=20
> Yes, good point, that would slow down data transmits, and would attach a
> marked increase in CPU utilisation. I guess authentication would do for
> now...

Well, implementing encryption is a good thing, but it should be optional
(and turned off by default, methinks :)

> | > o  Configuration file stuff has probably been implemented in a library
> | >    that could be used to keep code duplication down. Hash tables coul=
d be
> | >    used, it's easy in Perl :), and I know that glib implements all so=
rts
> | >    of structures. I realise this doesn't help you learn all of the as=
pects
> | >    of C :) but if you want to keep the code smaller, it could help...
> |=20
> | And I would *LOVE* to get my hands on some of this. Concepts I can learn
> | later -- so long as there's no "black boxes," I can always go back and
> | tear through code to finger it all out :)
>=20
> I'll have a look for those libs then. glib is used by GTK+ and I remember
> is has all sorts of list structures, (single/double linked etc.), and hash
> tables, plus all sorts of string manipulation. I don't think it's too
> heavyweight, which is always a worry, but it's far more bug-free than an
> implementation from scratch! :)

Agreed :) I wonder how bloated and/or portable glib is [ducks]. I forgot
to mention I'd like to incorporate libgtop (or some other similar
library that's portable and standardizes grabbing stats from a box).

> A quick idea I had, although probably already thought of, sorry I can't
> remember:
>=20
> We *could* implement the drivers as .so libs, and only load the drivers as
> required, just make sure the interface can work with this technique. It'd
> keep the server code smaller, the same lib could provide access to a
> number of similar screens...

This is probably a good idea. Now if someone could just refresh my
memory how .so libs actually work, and how to make it work in our little
project :)

--
William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

His designs were strictly honourable, as the phrase is: that is, to rob
a lady of her fortune by way of marriage.
		-- Henry Fielding, "Tom Jones"

--R+My9LyyhiUvIEro
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjmN4c8ACgkQgAeqhXR4/HpMCgCcCt8XLrptxGbRfSAiwn/o8Uo8
/CIAoN5+B3kxWCre40F4/8kp7PhVeufm
=MnOe
-----END PGP SIGNATURE-----


--R+My9LyyhiUvIEro
Content-Type: text/plain; charset=


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net
--R+My9LyyhiUvIEro--