Linux dpkg Software Report

[Ray Parrish]

Tim Frost wrote:
> On Thu, 2009-12-24 at 03:02 -0800, Ray Parrish wrote:
>   
>> Tim Frost wrote:
>>     
>>> On Tue, 2009-12-22 at 21:25 -0800, Ray Parrish wrote:
>>>   
>>>       
>>>> Hello,
>>>>
>>>> I hope I won't get flamed for this, but I have just completed my most 
>>>> ambitious script to date, and have completed the Linux dpkg Software 
>>>> Report script which takes output from dpkg, and formats it into html 
>>>> pages sorted by package section, such as Games, Editors, etc... and also 
>>>> generates an alphabetical index to the packages.
>>>>     
>>>>         
>>> Nice effort.
>>>
>>>
>>> One issue with the script as written is that it MUST be invoked with an
>>> absolute path name (i.e,
>>> "/home/tim/bin/SoftwareReport/LinuxdpkgSoftwareReport.sh", rather than
>>> "LinuxdpkgSoftwareReport.sh" or
>>> "./bin/SoftwareReport/LinuxdpkgSoftwareReport.sh" - which I tried
>>> first).  This is used to:
>>> - locate support scripts
>>> - determine where to write the output files
>>>   
>>>       
>> Is /home/tim/bin in your PATH environment variable on your system? If it 
>> is, and you installed the script there, it should run, unless the script 
>> does not have write priveleges in that folder.
>>     
>
> Yes, the directory /home/tim/bin is in my path.  But I installed in the
> directory /home/tim/bin/SoftwareReport, to keep this package isolated,
> and I didn't add that directory to my path.
>
>   
>> I do not know of any way to make the script itself be recognized without 
>> the path name unless it is installed somewhere that is on the PATH 
>> variable's definition. Perhaps you could enlighten me as to a method of 
>> doing this?
>>     
>>> Ideally, the program should be able to locate itself, and then derive
>>> the location of the support scripts, based on its location.
>>>   
>>>       
>> Which it does, it checks it's own name and path to find out where it has 
>> been executed from, and then creates the folder structure it needs, and 
>> creates the report files in those folders where ever it is ran from.
>>     
>
> OK.  I added the install directory /home/tim/bin/SoftwareReport to my
> path, and it is now working with just the script name - I see that the
> system is running
>  'bash /home/tim/bin/SoftwareReport/LinuxdpkgSoftwareReport.sh'
>
> so the script can see it's full path name, despite the fact that the
> command line I typed was 'LinuxdpkgSoftwareReport.sh'.
>   
Thanks for that information, and I'm glad you got it running. You may 
want to try the newer version 1.15 of the scripts set, as it has an 
install script, does not depend on knowing what folder it's started from 
[I'm installing it to usr/local/bin], and has a configuration file in 
/home$USERNAME/.dpkgSoftwareReport which can be used to specify the 
output folder for the files it generates.
>>> It should also use the user's preferred temp directory (or /tmp
>>> or /var/tmp), rather than writing files to a directory under it's
>>> install location.
>>>   
>>>       
>> I was not aware that this could be done without running the script with 
>> sudo, and thought it would be safer for people to have it writing files 
>> into folders they were allowed to write to without administrative 
>> privileges, so it cannot write to administrative areas of the drive 
>> structure.
>>     
>
> /tmp and /var/tmp can be written to by any user.  This means that you
> could create a report directory and files under either of those
> directories.  The only constraint is that a file (or directory) can only
> be removed by the owner, or by root/sudo.
>
> You can also write into the user's home directory (accessed as $HOME).
> By convention, packages that write configuration files (or store data
> long-term, such as evolution mail folders) in the user home directory
> create a directory named for the package, with a leading '.' which hides
> the directory from default list commands.
>
> So you could use $HOME/.SoftwareReport or $HOME/.softwarereport as the
> destination location.
>   
I'm using that sort of location in the new version for the configuration 
files dpkgSoftwareReport.conf, and LabelList.conf, and giving the user 
the ability to change the path to the data files with the first 
configuration file there, which simply contains the absolute path to 
where you want the output files to go.
>>> This allows an admin to install the scripts in a system directory such
>>> as /usr/bin, without needing to compromise system security.
>>>       
>> If I do that do I need to give root permission to execute the script?
>>     
>
> If this tool gets packaged so that it can be installed
> in /usr/local/bin (or /usr/bin, or any other location in the path for
> all users), you need to ensure that any user on the system can run it.
> This means that it will need to have 755 permissions (rwx for owner, and
> r-x for group and others).
>   
Someone else gave me the command for setting the proper permissions, and 
the install script now with version 1.15 takes care of that.
> If that level of packaging is desired, the background JPEG should be
> moved to an images directory, because it doesn't really belong in a
> binaries directory.
>   
Currently I'm keeping the image in the output files folder, but I just 
remembered that if the user changes the output path with the 
configuration file there is no mechanism to move the image file to the 
new location. That could be a small problem which I think I could solve 
by putting it in the folder with the configuration files.
>   
>>  
>> And where do I write it's output files to, /tmp  again? I actually 
>> prefer to write them to my personal user space, but I would like to be 
>> up to speed on normal practice for Linux, and am rather new to it so I 
>> did not know this was considered to be a requirement.
>>     
>
> Different people have different ideas here.
>
> Some people consider that /tmp and /var/tmp are intended for data that
> can vanish at any time. (For example, in Solaris /tmp is guaranteed to
> vanish on reboot).
>
> Persistent data that belongs to me should be written to my home
> directory.  Examples include:
> * personalised application settings and preferences,
> * mail files (evolution stores its files in .evolution/mail)
> * web browser cache and history, etc
>
>
> In this case, the factors for consideration are:
> * the program creates a new report every time it runs
> * I (as the user) may want to refer to yesterday's report,
> 	 rather than generating a new report.
>   
Bookmarking the report gives access to it at any time, and there is no 
need to regenerate the report, unless you install, or remove any 
packages since the last time you ran the script. I have not considered 
the case yet where a user may wish to generate a new report, and compare 
it to the old one.

I eventually would like to write code to generate an update to the 
report, instead of redoing the whole thing each time, but it will be a 
while before I get that done, as it is quite a bit more complicated than 
just making the files in the first place.

I would also like to add the installed date, and time for each package 
to the report if I can figure out where that information is kept. I know 
Synaptic Package Manager has that information, but do not know how to 
access it yet.
> * Should all users (on a multi-user system) be able to
> 	view the report?
>   
I haven't thought of any reason why all users should not have access to 
the report, but I suppose someone out there could have a reason for 
keeping that information from other users. Not sure what to do about 
that, except as I understand the file system, if a user generates the 
report in their home folder structure, it is not accessible by others 
unless they are sharing the folder it resides in for some reason. Am I 
correct on that point? [I'm a single user system, and have no reason to 
add a user to my system other than for testing purposes.]
> The first two factors imply that the report should not be stored in /tmp
> or /var/tmp, as they may be cleared on a reboot.
>
>
> The last question is probably out of scope at present, but could be a
> consideration in the future (in that case, the report might be created
> by a cron job, and stored in a public, world-readable location such
> as /var/cache/softwarereport)
>   
Thanks for that information, when you say world readable I'm assuming 
that means that all users on a system could access that location?

I don't really see a need to use a cron job to generate the report 
periodically unless software gets added, or removed on a regular basis 
on a particular system for some reason. The only time it needs to be ran 
is after changes to the packages installed.

Later, Ray Parrish

-- 
The Future of Technology.
http://www.rayslinks.com/The%20Future%20of%20Technology.html
Ray's Links, a variety of links to usefull things, and articles by Ray.
http://www.rayslinks.com
Writings of "The" Schizophrenic, what it's like to be a schizo, and other
things, including my poetry.
http://www.writingsoftheschizophrenic.com