Add the sensors-config tool
cover Add the sensors-config tool
Hello Jean, Hans,
a long time ago we've spoken about "DMI-based configuration". Unfortunately the last half year I only had a very reduced amount of time. But today I send my first proposal (patch) for this issue :)
A few words...
The tool is written in Python. I hope you can live with
this although this is another language in the lm-sensors project. I like the object oriented modules of Python and IMHO Python should be installed on every machine in a default installation.
What can you do with this tool?
1. Download config files from lm-sensors.org and build an archive
2. Install this archive into the file system (the path is hard-coded so far)
3. List the vendors off the available configs
4. List the board configs of a vendor
5. Install a config by vendor and board name
6. Show your systems' DMI data
7. Search a config based on the DMI data and install them
8. Remove the configs from the file system
NOTE: This is an early version. There are plenty of ToDos and probably some bugs. This is a request for comments what do you thing about the tool.
And now a short introduction.
To see a short help type
./sensors-config.py -h
Download and build archive
==============
1. First you have to create an directory for downloading.
andre@andre-laptop:~/src/sensors/prog/detect$ mkdir configs
2. Change to this directory
andre@andre-laptop:~/src/sensors/prog/detect$ cd configs/
3. Download the configs and build archive
andre@andre-laptop:~/src/sensors/prog/detect/configs$ ../sensors-config.py -t Fetch config for Evga/x58-SLI Fetch config for ASRock/AM2NF3-VSTA Fetch config for Epox/M1697 Fetch config for Epox/MF4-Ultra3 Fetch config for Abit/AA8-DuraMAX Fetch config for Abit/AA8XE-Fatal1ty Fetch config for Abit/AI7 Fetch config for Abit/AN7 Fetch config for Abit/AN8-SLI Fetch config for Abit/AV8 Fetch config for Abit/AX8 Fetch config for Abit/Aa7-Max Fetch config for Abit/Ag7 Fetch config for Abit/KN9-Ultra Fetch config for Abit/KV8-MAX3 Fetch config for Abit/Kv8Pro Fetch config for Abit/VA-20 Fetch config for DFI/CFX3200-M2-G-infinity Fetch config for DFI/Lanparty NF4 Expert Fetch config for DFI/Lanparty UT 790FX Fetch config for Asus/KFN4-DRE Fetch config for Asus/M2N-SLI Deluxe
The files are downloaded, some of unneeded "data" is stripped and an tarball is build in the same directory.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ ls -l insgesamt 32 drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Abit drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 ASRock drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Asus -rw-r--r-- 1 andre andre 5569 2010-01-13 21:11 configuration.tar.gz drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 DFI drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Epox drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Evga
This behaviour should be optimized. The directory should be created automatically and the configs should be removed. At the moment only a few configs are fetch from lm-sensors.org. Look at the configs hash in the source code.
Install the configuration from the archive
=====================
andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \ ../sensors-config.py -a configuration.tar.gz
This installs the configs to /usr/local/share/sensors/conf. So far the path is hard-coded. This should be changed.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ ls -l \ /usr/local/share/sensors/conf/ insgesamt 24 drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Abit drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 ASRock drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Asus drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 DFI drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Epox drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Evga
List the available configurations
================
To list all the vendors use -l option.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ \ ../sensors-config.py -l ASRock Abit Asus DFI Epox Evga
To list the boards of a given vendor use -b option.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ \ ../sensors-config.py -b Abit AA8-DuraMAX AA8XE-Fatal1ty AI7 AN7 AN8-SLI AV8 AX8 Aa7-Max Ag7 KN9-Ultra KV8-MAX3 Kv8Pro VA-20
Install a configuration
===========
You can manually install a configuration use -i option and an argument in the format VENDOR/BOARD.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \ ../sensors-config.py -i Abit/VA-20
This install the VA-20 config from Abit into /etc/sensors.d.
ATTENTION: This will overwrite all the existing configs in /etc/sensors.d.
You can also install a config based on DMI data. To show your systems' DMI data use -d.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ ../sensors-config.py -d
board_name: 8918DFG
board_vendor: LENOVO
board_version: Not Available
chassis_type: 10
product_name: 8918DFG
product_version: ThinkPad R61
sys_vendor: LENOVO
To search for a suitable config use -f. There are two options to find a config although there is no one suitable for your DMI data. Use option -V VENDOR and -B BOARD to overwrite the systems' DMI data. So you can simulate another machine.
andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \ ../sensors-config.py -f -V Abit -B VA-20 Found a suitable configuration: Abit/VA-20 Do you want to install this configuration? [y/N]: y This will delete older configurations. Do you want to proceed? [y/N]: y
Now the VA-20 config file should be installed in /etc/sensors.d.
Ok, that's for the moment. There are much work left. Have fun and I'de be happy to hear from you.
Thanks,
Andre
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Andre,
Thanks for working on this!
Quoted 7 lines · Andre Prendel
Hello Jean, Hans,
a long time ago we've spoken about "DMI-based configuration". Unfortunately the last half year I only had a very reduced amount of time. But today I send my first proposal (patch) for this issue :)
Quoted 7 lines
A few words...
The tool is written in Python. I hope you can live with
this although this is another language in the lm-sensors project. I like the object oriented modules of Python and IMHO Python should be installed on every machine in a default installation.
Hmm, I don't mind the archive download and building tool being written in python. But eventually there should also be a bash script which can be run from the systems initscript which will automatically find a config based on dmi and if found copy it to /etc/sensors-mb.conf (which can then be included from the regular sensors.conf). I don't think this part should be in python as on most systems none of the other initscripts use python.
Quoted 3 lines
What can you do with this tool?
1. Download config files from lm-sensors.org and build an archive
Hmm, I see it currently has a hardcoded list of config files, it would be good if it could discover the config files dynamically based on what is available on lm-sensors.org
Quoted 2 lines
2. Install this archive into the file system (the path is hard-coded so far)
I think the path should be under /var/lib, as the contents can change by running the same version of the tool again (if the wiki is updated).
Quoted 5 lines
3. List the vendors off the available configs
4. List the board configs of a vendor
5. Install a config by vendor and board name
6. Show your systems' DMI data
7. Search a config based on the DMI data and install them
I see currently this assumes that the name as on the wiki (in the url on the wiki), is the same as in the dmi info, this is not necessarily true. There was a project similar to yours a while ago, which added magic comments to the config files to state for which dmi strings the config was valid. note that one config could be valid for multiple boards.
Quoted 6 lines
8. Remove the configs from the file system
NOTE: This is an early version. There are plenty of ToDos and probably some bugs. This is a request for comments what do you thing about the tool.
Disclaimer: I have not tested it.
What I think, well I like that someone is working on this, and I like that you are using the wiki as "database", as with previous attempts part of the problem was that both a tool and a website needed to be developed simultaneously.
As for comments, see above.
Thanks & Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 1 line · Hans de Goede
Hi Andre,
Hi Hans,
Thanks for your feedback :)
Quoted 18 lines
Thanks for working on this!
Quoted 7 lines · Andre Prendel
Hello Jean, Hans,
a long time ago we've spoken about "DMI-based configuration". Unfortunately the last half year I only had a very reduced amount of time. But today I send my first proposal (patch) for this issue :)
Quoted 7 lines
A few words...
The tool is written in Python. I hope you can live with
this although this is another language in the lm-sensors project. I like the object oriented modules of Python and IMHO Python should be installed on every machine in a default installation.
Quoted 7 lines
Hmm, I don't mind the archive download and building tool being written in python. But eventually there should also be a bash script which can be run from the systems initscript which will automatically find a config based on dmi and if found copy it to
/etc/sensors-mb.conf(which can then be included from the regular sensors.conf). I don't think this part should be in python as on most systems none of the other initscripts use python.
What do you mean with this /etc/sensors-mb.conf? I don't know such a config file. My plan was to copy the file to the /etc/sensors.d directory. Configs in this directory overwrites the default sensors.conf config file.
I don't think we have to copy the file on every startup. It should be enough to do this while installing lm-sensors or if an update is available, right? But it's right, we need an trigger for the dmi-based configuration. This could be done from 'make install'.
Just a few words about my intention how to use the config-tool.
The fetching and archive building part is only for config maintainers (e.g. you, Jean or me). If a new config is available or something changed a maintainer builds a new archive. This archive should be provided via lm-sensors.org.
User can download the archive and use the config-tool the install it. We could improve the tool to inform the user for new updates and download the archive automatically.
Quoted 7 lines
Quoted 3 lines
What can you do with this tool?
1. Download config files from lm-sensors.org and build an archive
Hmm, I see it currently has a hardcoded list of config files, it would be good if it could discover the config files dynamically based on what is available on lm-sensors.org
That's right. We could maintain a file similar to the format generated by the wiki.
http://lm-sensors.org/wiki/Configurations
Such a file is easy to parse and might contain only confirmed configurations. Or do you know a way to scan remote directories via HTTP?
Quoted 6 lines
Quoted 2 lines
2. Install this archive into the file system (the path is hard-coded so far)
I think the path should be under
/var/lib, as the contents can change by running the same version of the tool again (if the wiki is updated).
It seems you're right again. The FHS says data in /usr/share must be purely static data. I will change the path.
Quoted 9 lines
Quoted 5 lines
3. List the vendors off the available configs
4. List the board configs of a vendor
5. Install a config by vendor and board name
6. Show your systems' DMI data
7. Search a config based on the DMI data and install themI see currently this assumes that the name as on the wiki (in the url on the wiki), is the same as in the dmi info, this is not necessarily true.
The names don't have to exactly match. The lookup is case-insensitiv and the "wiki name" have to be part of the "dmi name". I did some test with the data Rudolf Marek sent in the first thread.
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018982.html
Quoted 4 lines
There was a project similar to yours a
while ago, which added magic comments to the config files to state for which dmi strings the config was valid. note that one config could be valid for multiple boards.
Yes, one config for multiple boards doesn't work at the moment. Probably we have to introduce some meta data for this issue. Maybe we could support single boards for now and add this feature later on!?
Quoted 14 lines
Quoted 6 lines
8. Remove the configs from the file system
NOTE: This is an early version. There are plenty of ToDos and probably some bugs. This is a request for comments what do you thing about the tool.
Disclaimer: I have not tested it.
What I think, well I like that someone is working on this, and I like that you are using the wiki as "database", as with previous attempts part of the problem was that both a tool and a website needed to be developed simultaneously.
Quoted 5 lines
As for comments, see above.
Thanks & Regards,
Hans
Thanks,
Andre
PS: Sorry for the subject mismatch (RFC PATCH vs. PATCH RFC) :)
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi,
Quoted 33 lines · Andre Prendel
Quoted 1 line · Hans de Goede
Hi Andre,
Hi Hans,
Thanks for your feedback :)
Quoted 18 lines
Thanks for working on this!
Quoted 7 lines · Andre Prendel
Hello Jean, Hans,
a long time ago we've spoken about "DMI-based configuration". Unfortunately the last half year I only had a very reduced amount of time. But today I send my first proposal (patch) for this issue :)
Quoted 7 lines
A few words...
The tool is written in Python. I hope you can live with
this although this is another language in the lm-sensors project. I like the object oriented modules of Python and IMHO Python should be installed on every machine in a default installation.Quoted 7 lines
Hmm, I don't mind the archive download and building tool being written in python. But eventually there should also be a bash script which can be run from the systems initscript which will automatically find a config based on dmi and if found copy it to
/etc/sensors-mb.conf(which can then be included from the regular sensors.conf). I don't think this part should be in python as on most systems none of the other initscripts use python.
Quoted 5 lines
What do you mean with this
/etc/sensors-mb.conf? I don't know such a config file. My plan was to copy the file to the/etc/sensors.ddirectory. Configs in this directory overwrites the default sensors.conf config file.
Ah cool, yes that is pretty much the mechanism I had in mind, although I believe the file should be renamed to motherboard.conf on copy-ing, see below.
Quoted 4 lines
I don't think we have to copy the file on every startup. It should be enough to do this while installing lm-sensors or if an update is available, right? But it's right, we need an trigger for the dmi-based configuration. This could be done from 'make install'.
Erm most people won't be doing make install, but will be installing packages from a distro. Also think about cases like a livecd / live usb stick, where the hardware must be discovered automatically each boot, as it might be completely different.
An other scenario is the user swapping motherboard. So, just like the rest of a modern Linux distributions dynamically discovers all hardware each boot (swapping a video card or a motherboard does not require making any configuration files now a days), lm_sensors should dynamically discover and configure sensors (where possible).
So I disagree with "I don't think we have to copy the file on every startup." this is also why the file should have a standard name like /etc/sensors.d/auto-motherboard.conf
And I would even go as far as to say, that if no valid config was found that file should be removed.
Quoted 12 lines
Just a few words about my intention how to use the config-tool.
The fetching and archive building part is only for config maintainers (e.g. you, Jean or me). If a new config is available or something changed a maintainer builds a new archive. This archive should be provided via lm-sensors.org.
User can download the archive and use the config-tool the install it. We could improve the tool to inform the user for new updates and download the archive automatically.
Ok.
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
What can you do with this tool?
1. Download config files from lm-sensors.org and build an archive
Hmm, I see it currently has a hardcoded list of config files, it would be good if it could discover the config files dynamically based on what is available on lm-sensors.org
Quoted 9 lines
That's right. We could maintain a file similar to the format generated by the wiki.
http://lm-sensors.org/wiki/Configurations
Such a file is easy to parse and might contain only confirmed configurations. Or do you know a way to scan remote directories via HTTP?
No not really, you could parse the index page(s), but having an easier to parse index file somewhere on lm-sensors.org is fine.
Quoted 20 lines
Quoted 6 lines
Quoted 2 lines
2. Install this archive into the file system (the path is hard-coded so far)
I think the path should be under
/var/lib, as the contents can change by running the same version of the tool again (if the wiki is updated).It seems you're right again. The FHS says data in
/usr/sharemust be purely static data. I will change the path.Quoted 9 lines
Quoted 5 lines
3. List the vendors off the available configs
4. List the board configs of a vendor
5. Install a config by vendor and board name
6. Show your systems' DMI data
7. Search a config based on the DMI data and install themI see currently this assumes that the name as on the wiki (in the url on the wiki), is the same as in the dmi info, this is not necessarily true.
Quoted 6 lines
The names don't have to exactly match. The lookup is case-insensitiv and the "wiki name" have to be part of the "dmi name". I did some test with the data Rudolf Marek sent in the first thread.
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018982.html
Ok, the problem with this approach is that renaming wiki pages is not trivial AFAIK. So if the wiki page name is poorly chosen (or atleast chosen in such a way it does not match the DMI name), we are in trouble I really believe we need a way to embed the DMI strings to search for inside the configuration files.
Quoted 10 lines
Quoted 4 lines
There was a project similar to yours a
while ago, which added magic comments to the config files to state for which dmi strings the config was valid. note that one config could be valid for multiple boards.Yes, one config for multiple boards doesn't work at the moment. Probably we have to introduce some meta data for this issue. Maybe we could support single boards for now and add this feature later on!?
If the one config file multiple boards case was the only problem, sure, but see above.
About all this also see:
http://sensors4mobo.eberian.com/
Which is something similar to what you were doing now, but which was created as a project for private use and never got any bigger then that.
I'll forward you the announcement mail of this project.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 1 line · Hans de Goede
Hi,
Hello Hans,
Quoted 10 lines
Quoted 6 lines
What do you mean with this
/etc/sensors-mb.conf? I don't know such a config file. My plan was to copy the file to the/etc/sensors.ddirectory. Configs in this directory overwrites the default sensors.conf config file.Ah cool, yes that is pretty much the mechanism I had in mind, although I believe the file should be renamed to motherboard.conf on copy-ing, see below.
Ok.
Quoted 16 lines
Quoted 4 lines
I don't think we have to copy the file on every startup. It should be enough to do this while installing lm-sensors or if an update is available, right? But it's right, we need an trigger for the dmi-based configuration. This could be done from 'make install'.
Erm most people won't be doing make install, but will be installing packages from a distro. Also think about cases like a livecd / live usb stick, where the hardware must be discovered automatically each boot, as it might be completely different.
An other scenario is the user swapping motherboard. So, just like the rest of a modern Linux distributions dynamically discovers all hardware each boot (swapping a video card or a motherboard does not require making any configuration files now a days),
lm_sensorsshould dynamically discover and configure sensors (where possible).
Quoted 6 lines
So I disagree with "I don't think we have to copy the file on every startup." this is also why the file should have a standard name like
/etc/sensors.d/auto-motherboard.confAnd I would even go as far as to say, that if no valid config was found that file should be removed.
Ok, you've totally convinced me. So I will add (or extend the existing?) initscript to do this discovery.
Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
What can you do with this tool?
1. Download config files from lm-sensors.org and build an archive
Hmm, I see it currently has a hardcoded list of config files, it would be good if it could discover the config files dynamically based on what is available on lm-sensors.org
That's right. We could maintain a file similar to the format generated by the wiki.
Quoted 8 lines
Quoted 4 lines
Such a file is easy to parse and might contain only confirmed configurations. Or do you know a way to scan remote directories via HTTP?
No not really, you could parse the index page(s), but having an easier to parse index file somewhere on lm-sensors.org is fine.
Ok.
Quoted 16 lines
Quoted 16 lines
Quoted 11 lines
Quoted 2 lines
2. Install this archive into the file system (the path is hard-coded so far)
I think the path should be under
/var/lib, as the contents can change by running the same version of the tool again (if the wiki is updated).I see currently this assumes that the name as on the wiki (in the url on the wiki), is the same as in the dmi info, this is not necessarily true.
The names don't have to exactly match. The lookup is case-insensitiv and the "wiki name" have to be part of the "dmi name". I did some test with the data Rudolf Marek sent in the first thread.
Quoted 8 lines
Ok, the problem with this approach is that renaming wiki pages is not trivial AFAIK. So if the wiki page name is poorly chosen (or atleast chosen in such a way it does not match the DMI name), we are in trouble I really believe we need a way to embed the DMI strings to search for inside the configuration files.
Ok, I will will read some more about the sensors4mobo project and then we can discuss an approach.
Quoted 17 lines
Quoted 10 lines
Quoted 4 lines
There was a project similar to yours a
while ago, which added magic comments to the config files to state for which dmi strings the config was valid. note that one config could be valid for multiple boards.Yes, one config for multiple boards doesn't work at the moment. Probably we have to introduce some meta data for this issue. Maybe we could support single boards for now and add this feature later on!?
If the one config file multiple boards case was the only problem, sure, but see above.
About all this also see:
http://sensors4mobo.eberian.com/
Quoted 9 lines
Which is something similar to what you were doing now, but which was created as a project for private use and never got any bigger then that.
I'll forward you the announcement mail of this project.
Regards,
Hans
Thanks,
Andre
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors