BIT METER OS 0.7.6 (stable) & 0.8.0 (experimental)

[Mike Walsh]

**ALTERNATE MIRROR**

The various .pets and .debs mentioned throughout the course of this thread are now mirrored at MediaFire. You can never have too many backups..!

======================================

Geoffrey's work:-

0.8.0 for 32-bit
0.8.0 for 64-bit
0.7.6 all-Pups for 32-bit (w/database installer)
0.8.0 all-Pups for 32-bit (w/database installer)

All can be found here:- https://www.mediafire.com/folder/8uqgcd ... erOs_.pets

======================================

For those of you wanting the original .debs for BitMeter, they are here:-

0.7.6 (32-bit)
0.8.0 (32-bit)
0.7.6 (64-bit)
0.8.0 (64-bit)

All can be found here:- https://www.mediafire.com/folder/5v0gm1 ... erOS_.debs

Credits to Rob Dawson for the last four. These can, of course, also be found on Rob's 'CodeBox' website.

-------------------------------------------------------------------------------------

Regards,

Mike.

[davids45]

G'day,

I tried the bmsync option to see if another computer on my home network would provide its bitmeter data via the command-line bmsync option.

As per the attached pinboard image, I could not connect to this other computer (HP desktop, running frugal tahr-pup, ethernet address=192.168.2.11 host-name=puppypc9528). The reason for not connecting was slightly different between the address method and host method, if that matters?

There is no active firewall on either computer Pup.

I can ping the other computer from my main desktop computer.

Bitmeter is running on both as localhost:2605 so I assume the port is the normal one. The -p 2605 parameter made no difference

Any suggestions?

David S.

[Mike Walsh]

Hi, David.

It rather looks like you've performed the exact same steps as me.....and obtained precisely the same results as me; zilch!

I can only assume that we're doing something wrong...but what? I'm no whiz with the terminal. I rather assumed that somebody with a modicum of experience using the blasted thing would have 'bmsync' operational within a matter of minutes....

Glad I'm not the only one who seems to be making a 'pig's ear' of it! (No insult intended.)

I'm going to have another look into this myself.....cause syncing with the common database over Samba on the LAN is a non-starter. There's got to be a way of doing this.....I will find it..!


Regards,

Mike.

[davids45]

G'day,

Looking on the Bitmeter Forum, I found some guidance from Rob Dawson on setting up bmsync to collect data from other network computers.

The 'other' computer needs to be set up to be ready to supply data from its Bitmeter to the main computer. Three command line instructions are needed for this as per the following quote from the Bitmeter Forum posting by Rob Dawson:

http://codebox.org.uk/jforum/posts/list/5012.page - the link to the post

First, you need to find the IP address of your laptop
Then, on your laptop open a Command Window
Enter the following 3 commands into the command window, pressing Enter after each:
bmdb webremote
bmdb webstop
bmdb webstart
Now on your PC, open a web browser and try to view the web interface for your laptop, using the IP address you found earlier. If the IP was for example 192.168.1.2 then the address to use in your web browser would be http://192.168.1.2:2605
If this doesn't work chances are you have a firewall running on your laptop, you need to configure this to allow incoming connections to TCP port 2605 (see Google or your firewall documentation)
Once you can see the laptop web interface you are ready to sync the data to your PC, to do this open a command window on your PC this time, and type:
bmsync -a laptop 192.168.1.2
(except using the correct IP address of your laptop)
Once the bmsync command has finished just refresh web interface on your PC and you should see all the information from your laptop as well. To change which set of data you see, adjust the settings on the Preferences/Data Filter tab.
Whenever you want to update your PC with the latest data from your laptop, just run the 'bmsync' command again.

This worked for me on a test desktop so that my main Bitmeter data summary now includes data rows from the other computer (see attached image).
I'm assuming I should stop the bmdb 'daemon' on the other computer once finished(?), and maybe try a script of these three lines to set up each 'other' computer when desired? Anyone want to do a GUI for this?

Anyway, now to try this with the other network desktops then the Windows7 laptop .

Fingers crossed.

David S.

[gcmartin]

Corrected
@DavidS45 has provided instructions for having WAN use data from all PCs on the LAN to be reported by Bit Meter, in a single BM local webpage. His instructions are for the "server" BitMeter and a set of instructions for each client on the LAN who accesses the internet.

Turns out that the BM PET supplies everything needed for each PC, client and server, to participate in contributing to a common BM reporting of internet data usage.

So, as I understand what is shared:
All PCs

• Bit Meter must be installed
• All PCs must be able to URL their browser to the "Bit Meter Server"
• Following these steps all PCs data will be "sync'd" with a common database (db)

First, on each "Bit Meter Client" (these are the PUPs who pass their data to "BM's db")
Open a terminal and enter the following

Code: Select all

# bmdb webremote
# bmdb webstop
# bmdb webstart
# ip addr

You must record/remember the IP address as it is needed by the BM Server to collect each local PC's data. The IP addresses are referred, below, as client's IP address.

On the "Bit Meter Server" (this is the PUP where the db is hosted)

• Ensure your browser can access the BM client(s) by entering the client's IP address and port number (for example, as shown by @DavidS45; "http://192.168.1.2:2605")
• Open a terminal and enter the BMsync command (for example, as @DavidS45 shows). This will allow server collection of the db data from this client

  Code: Select all

  bmsync -a  192.168.1.2

• If there are other BM PCs on your LAN, you must enter a bmsync command for their IP address, as well. For example a BM PC client at 192.168.1.3 would require:

  Code: Select all

  bmsync -a  192.168.1.3

When a BM command is completed at the BM server for each BM client, open/reopen/refresh your browser to the server's IP address and port number.

Summary
Each PC has a common BM installation with their own local data use database. A single PC designated the "server" collects each db from the other BM PCs and reports via a single screen showing all traffic.

ALL Thanks for syncing goes to @DavidS45 and Geoffrey and Mike and Mike and MIke, et.al.
Edited: to properly reflect what is needed for data collection and reporting.

[davids45]

G'day gcmartin,

If I understand your post correctly, I think it is the other way around for the bmdb stop-start scripts.

The three terminal/console lines:

bmdb webremote
bmdb webstop
bmdb webstart

are entered in the terminal on each 'client' computer. During my first and only test, each bmdb command got a response from the terminal on my other or client computer about its bmdb web status .

These 3 scripts should set up each non-main 'client' computer to be a temporary 'server' for the main .db file computer so the main computer can access the new Bitmeter data with the bmsync command.

When bmsync is entered from the main BM .db computer with the IP address of the 'client' computer, the Bitmeter data is read from the 'client' and any new data added/updated to the main Bitmeter .db file.

I'll confirm this is the way to do it when I check on my other non-main computers by adding their Bitmeter data to my main .db file.

In answer to your Questions, I have not used SAMBA, just the BM utilities so only my main .db computer has the complete BM data.

David S.

[davids45]

G'day,

Just ran a bmdb script (quoted below) on two more networked computers (at 192.168.2.11 and 192.168.2.9, both already with Bitmneter-0.8 installed of course) to make BitMeter on my main computer read their .db files and sync this information into my main .db file.

#!/bin/sh

bmdb webremote
bmdb webstop
bmdb webstart

I did see an ERR message included in the output line on the host console. So maybe I should enter the three commands for bmdb webremote/stop/start as separate inputs? Should such a script go into /root/Startup? Should the bmdb webremote script be stopped once its host has been sync-ed from the main computer?

But running in a terminal from my main computer,

bmsync 192.168.2.11

(and later "bmsync 192.168.2.9" for the fourth computer)

the data seemed added each time to the main .db file (see attached screen shot with the extra coloured lines of Downloads and Uploads in the Summary being for the now 3 hosts as indicated by their IP addresses on the final (blue) line of this Summary).

I will re-run this sync-ing in a few days time to see what happens.

David S.

[Mike Walsh]

Hi, David!

My goodness, you have been a 'busy bee' while my back's turned. This is looking promising...

Might I impose upon you for a wee bit of clarification? My set-up is basically this:-

My big ol' Compaq desktop runs 4 'pups'; TahrPup, Slacko 570, ETP's 'ChromeBook' pup, and Precise 571. For argument's sake, we'll call this the 'server'. This is the one I shall use to collect information to. The IP address for all of these is 192.168.1.71.

My 'common' bitmeter.db database sits in a further small partition on its own, also on this one's hard drive. This is what's been sym-linked to each of the four Pups on the Compaq.

My other machine, my old Dell Inspiron 1100 laptop, runs Tahrpup. For argument's sake, we'll call this one the 'client'. This is the one whose data I want to add to the main database. The IP address for this is 192.168.1.65.

Both of these IP addys are 'static', so they don't change. It's a must for Samba-TNG, 'cos the poor thing gets a mite confused if the addy keeps changing. For some reason (and I believe this is because of the way the DHCP servers work), occasionally it'll be 192.168.1.67, whereas other times it'll be 192.168.1.71.

For the 'buntus, it's always '67'.....but with the Puppies, it seems to change from time to time. Doesn't matter for web browsing, but for certain IP address-dependent scripts & such-like, it throws things right out. Hence the static addresses.

So; to recap, I want to add data from 192.168.1.65 to the database on 192.168.1.71. What's my next move? I think I see how to do it, from your instructions....but what's confusing me is that you and GCM seem to have a difference of opinion as to which way round all this is done. I understand you've been following information from the BitMeter Forums, yes?

I'm getting quite excited now....!


Regards,

Mike.

[Mike Walsh]

Well, now; this is what I call very odd....

In Tahrpup, I followed the instructions for 'bmsync' from the CodeBox forum; substituting, in my case, my hostname (MiqPup) for 'laptop', and using 192.168.1.65:2605.

Came up in the browser nicely.....a 'mirror' of what the Dell was showing. Perfect. I synced the data to the Compaq, using 'bmsync -a'. The Compaq's browser showed two sets of information. Excellent.

It wasn't until I booted into Slacko (and then 'ChromePup') that I realised that BitMeter appeared to have stopped working...! I tried restarting in the terminal; nothing. Upon further investigation, it appeared that /var/lib/bitmeter's sym-link to the common data partition no longer existed. Curiouser & curiouser.....

I've had to recreate a new database, thus losing all the data to date. All attempts to re-symlink the old database came to nothing. Can't understand why.

Anybody got any ideas on this one?


Regards,

Mike.

[davids45]

G'day Mike Walsh,

I have not tried bmsync-ing from another Pup on this my multi-Pup main computer to the other computers on my home network. Nor have I booted with another Pup on this machine since the successful bmsync to check if BitMeter is still working on those Pups I have had time to install it to (Friday is minding-the-grandkids day and we've been to the zoo).

So, when I do these checks (soon, now that 'they' have gone home with their mother ), I'll make a back-up copy of the main .db file just before I do anything.

I have only used the basic parameters so far:
- on the 'other computers', just the three command lines entered via the terminal or as a script.

bmdb webremote
bmdb webstop
bmdb webstart

Each line produced an encouraging text response in the terminal.
Still not sure if I should terminally stop the webremote once the data exchange has occurred or just shutting down the other-computer is adequate.

I then switched to my main computer (its IP address is not required (or actually known )). In its terminal, I typed just:

bmsync 192.168.2.xx

(that is, just the other computer's IP address after the bmsync - no extra parameter nor did I try the other computer's puppypc name)

And this added the other computers' BM data to the .db file on my main computer's data partition. When I run it again, I'll check if I see an ERR within the terminal text response as the sync occurs.

This bmsync process reminded me of an app for my wifi-ed android phone that enables it to transfer files to my data partition. The app sets up the phone as a local network server and displays the IP address I need to enter into my computer browser to access the android phone files (photos mostly) so I can download/copy them onto my data partition.

As I see it, BitMeter in sync-ing sets up each 'other computer' as a server of the BM data on it for the main computer as a client to add or update to its .db file.

Plenty to play with still.

David S.

[Mike Walsh]

Hi, David.

Oh, I'm not saying there's anything wrong with the basic principle behind all this. It may be a glitch at my end; I've installed Dropbox over the last couple of days, and also added Comodo's AV for Linux to Precise. I know there's no need for it, but I like to check things about once a month.

The version I use is the one for 'other Linux', which comes as a self-contained, stand-alone tar.gz package from Comodo. I also have it on Tahrpup. I have a lot of friends with Windows machines, and like to make sure I'm not passing on crud to them, albeit unknowingly. Install was very straightforward in Tahrpup, but I made a bit of a hash of it in Precise initially, so that may have been responsible.....during the set-up (in the terminal), there was some stuff came up about BitMeter; I guess I should have paid more attention!

This could all be self-inflicted.....


Regards,

Mike.

[davids45]

G'day,

A few more days of bmsync-ing with just a few problems with BitMeter not running when or as expected. But mostly good results.

Updating bmsync data
Yesterday, as my first updatings after syncing my three 'other desktops' the day before, I again bmsynced two of my three 'other' desktops.

But before doing the bmsync, when I first opened BitMeter on my main desktop, and looked at the Summary, the 'Today' values for the three 'other computers' were a lot of "NaN PB". 'NaN PB' means there is no current data for that section of the table. Which made sense as I had not yet bmsynced these computers for 'Today' so I only had their prior usage values which were displayed in the 'Month' column.

I did not need to re-run the bmdb remoteweb scripts on these other computers as both responded to their bmsync call from my main desktop (e.g. bmsync 192.168.2.10). No changes in their IP addresses (yet - these are not static ).

New 'Today' data now appeared for these two on my main BitMeter 'Summary'. Attached screen-shot shows these and the final 'Today' rows for the third un-synced computer still as 'NaN PB'.

So today, I tried bmsync-ing the third desktop. On booting up this third desktop, I found BitMeter was running but not capturing as its 'Monitor' display showed no activity and its 'Today' was all NaN PBs.

So on this 3rd desktop, I needed to re-start bmcapture. In a terminal, I entered:

cd /etc/init.d/
./bitmeter restart

and saw the stopping and re-starting messages, and then saw the 'Monitor' was now active on the browser.

Computer #3 (at 192.168.2.9) synced without need for the bmdb webremote scripts and its data appeared on my main .db Summary. There was an ERR included in the terminal display (see attachment) but data apparently synced nonetheless.

The two un-synced desktops were now all NaN PB for 'Today' but had yesterday's synced values in their 'Month' and 'Year'.

NaN PB = no capturing = need to re-start bmcapture
I had the same 'no-capturing' problem at start-up with another Pup on my main computer which was fixed by this manual re-starting from /etc/init.d. I wonder if during booting a Puppy, BitMeter does not always start correctly, perhaps due to clashing occasionally other programs also starting up at the same time. Maybe a small 'sleep' in the BitMeter start-up script in /root/Startup would be helpful??

This no-capturing (=NaN PBs in the Summary) is really the only recurrent problem I've had with BitMeter, but so far, has been fixed with the terminal 'bitmeter restart' scripting .

I've also tried an export to csv of data which looked OK . I don't know if it is possible to sum all the data being synced as another set of rows as I am assuming the 'Summary' is only for the individual computers using BitMeter on the network.

Not ventured onto my Windows7 laptop (for Fitbit) with BitMeter yet.

BitMeter is still looking like a good package for Puppy.

David S.

[Mike Walsh]

Hi, David.

I think I'm getting on top of it. I re-ran bmsync from 'ChromeBook' Pup, thus:-

Code: Select all

bmsync -a MiqPup 192.168.1.65

MiqPup being the Dell's hostname for Tahrpup, which is the only Pup that will run on it! Didn't need to re-run 'bmdb webremote', as it was already set up. Like you, I too got an

Code: Select all

ERR -1

in the sync procedure, but, as you've found out yourself, the synchronisation still appears to go ahead; in this case with

Code: Select all

 2904 lines added

So; that all appears to be working smoothly (see attachment). Thanks for your help (and research) with all this; nice one..!! And, 'touch wood', so far, re-booting into my other Pups, BM is starting up as expected. I suspect the Comodo AV for Linux installation in Precise the other night messed things up, because I made a real hash of installing it initially, and had to re-do it a couple of times..! I installed it to 'TahrPup' about 5 months ago, and had totally forgotten the rather cumbersome routine you have to go through in order to get it working. And I use it maybe once a month...purely and simply as an 'on-demand' scanner, scanning whatever folder(s) you specify at the time.

-----------------------------------------------------------------------------------

As far as a 'sleep' delay is concerned, well..... If you recall, Geoffrey found out that the most effective way to get BitMeter up & running each time at boot was to insert a sleep statement into xbitmeter, thus:-

Code: Select all

#!/bin/sh

IFCONFIG="`ifconfig | grep '^[pwe]' | grep -v 'wmaster'`"
while [ "$IFCONFIG" != "" ]; do
   sleep 1
    ping -c 1 8.8.8.8
    if [ $? -eq 0 ];then
      break
   else
      ping -c 1 www.google.com
      if [ $? -eq 0 ];then
         break
      fi
   fi
done
sleep 15
/etc/init.d/bitmeter restart
/etc/init.d/bitmeterweb restart

Having

Code: Select all

sleep 15

inserted at line 16 in the original xbitmeter script, along with

Code: Select all

/etc/init.d/bitmeterweb restart

added at line 18.

But Geoff did say that the 15 second delay, although it worked for his set-up, might need adjusting for individual cases. So, I would suggest that you try increasing the delay for whichever of your boxes is proving problematical. Certainly can't hurt to try, can it?

Let us know if it works.


Mike.

[Mike Walsh]

Hi, David.

I've also tried an export to csv of data which looked OK . I don't know if it is possible to sum all the data being synced as another set of rows as I am assuming the 'Summary' is only for the individual computers using BitMeter on the network.

You should find that the 'Summary' tab will show the aggregate total from the main, sym-linked 'common' bitmeter.db database. That's how it works for me, anyway.

I honestly don't know how you would go about presenting the 'Summary' total as a separate set of rows on your multiple read-out.....your BitMeter tab is already looking rather crowded..!


Mike.

[Mike Walsh]

Hi again, David.

Reading through the CodeBox forums, I came across the statement (from Rob) that some people have found problems with using bmsync in 0.8.0, but that using 0.7.6 didn't give such problems.

So; I'm now wondering whether it might be worth re-setting everything up again, but this time with 0.7.6...

Need to sleep on this..!


Regards,

Mike.

[davids45]

G'day Mike,
I still have a few un-bit-metered Full Pups and plenty of Frugal Pups (bitmeter sfs?) so I will try the pet of 0.7.6 and see if it is easier in starting and sync-ing.
I expect that 0.7.6 can use the same .db file as 0.8?

var/log/bitmeter?
I have an occasional problem with running the 32-bit 0.8 pet because it did not set up the /var/log/bitmeter directory. mikeb noted this problem in one of his posts (http://www.murga-linux.com/puppy/viewto ... &start=146).

Bitmeter in older Pups?
I continually find PAE Pups have random kernel panics in my 2GB RAM desktops and have just about decided PAE is dangerous when not needed (<4GB RAM). So I have quite a few old non-PAE Pups to check out BitMeter (and new non-PAE Pups where I can get them).
I just installed Geoffrey's 0.8 32-bit pet to this Full SnowPup-016 (kernel-2.6.35) and had to manually create the /var/log/bitmeter/ directory to use the stop-restart routine. Otherwise everything looks OK in this slightly older Pup.

Will give 0.7.6 a try on some Pups and report.

David S.

PS:
Tried just now the 32-bit 0.7.6 pet in a couple of older Pups which:
- did not create the /var/log/bitmeter directory,
- gave no prompt at installation for a link to an existing .db file, and
- I had to add "index.html" to the localhost address to see the monitor running.
So I'm thinking the 0.7.6-all32 pet I downloaded today is not an updated version with these thread-mentioned bugs fixed in it?

[Mike Walsh]

Hi David.

Can't find it at the moment (so as to give you a quote), but I was having a read through the BitMeter Forums last night.....and came across one interesting tit-bit of information.

I expect that 0.7.6 can use the same .db file as 0.8?

Apparently not. If you're using 0.7.6, you can update to 0.8.0 quite happily; the 'bitmeter.db' file gets updated from version7 to version8, and all carries on as normal.

However; if you want to revert to the older version from the newer version, BitMeter won't play ball. It won't revert to the older version database without a complete uninstall, and re-install. If you do that, don't forget to delete /var/lib/bitmeter before you re-install.

There is one way to revert to the older database; you'll need to send your bitmeter.db file to Rob Dawson, and he'll perform a switch on it for you. Or perhaps he could tell you what code would need changing...

------------------------------------------------------------------------------------------------

If you go down the re-install route, I suspect you'll also need to delete (or at least move) your bitmeter.db file in your common data partition, or folder....whichever you're using. You'll have to start from scratch; uninstall all instances of bitmeter from every PUP, then with the first re-install of the older version, reset up your sym-linked bitmeter.db (just how we did in the beginning).

I'm guessing that Geoffrey's 0.7.6 bitmeteros-allpups .pet will work fine once you have 0.7.6 installed for the first time.....if you notice, we don't have a 0.7.6 bitmeteros-i386.pet, do we? That being the case you may have to install the .deb version initially (just like I did), and add the xbitmeter.tar.gz that Geoff provided early in the thread to 'Startup', manually.

Doesn't really surprise me that the newest version got all the development work, and the older one was just tagged on almost as an afterthought! We're so conditioned to expecting the newest version of everything, almost before it's hit the shelves; I blame Windoze for that...you have to have the newest versions of everything for your own safety! Here in Puppy-land, it's not quite such a 'must-have'...

I'll be honest with you. I, personally, prefer the interface of the older version. I can't see any reason why you shouldn't be able to sym-link multiple instances of 0.7.6's bitmeter.db file, same as with the newer version. And I've got enough experience with this thing by now, that I think I've got a reasonable chance of making it work. I don't think the setup will care whether it's working with 0.7.6 or 0.8.0; the files have the same names. You just need to make sure that you rename the appropriate bitmeter.db.new file (in this case 0.7.6's) when you do the initial re-install.

And of course, remember to edit xbitmeter to include the sleep statement.....after you've added it manually..!

I'll be trying this at some point in the next few days; I'm not fussed about losing data, as I haven't built-up any great amount at the moment, so..... Watch this space.


Regards,

Mike.

[davids45]

G'day Mike,

Thanks for the reply re my initial tries with the version 0.7.6 pet.

Based on your information and my couple of 0.7.6 tests with older Pups, I don't see any reason to switch to 0.7.6 from 0.8 for Puppy.

We seem to have our 'improved' 0.8 running in Puppies now without dramas - do you have any more detail about those problems reported from elsewhere with 0.8 ? Were these with the Linux or the Windows BitMeter-0.8 version, for example?

(Perhaps luckily) I hadn't got as far as trying to manually link the 0.7.6 installs to my main ( 0.8 ) .db file because of the non-appearance of the which-.db-option-dialog-box and the other minor glitches, making me think the 0.7.6 .pet was not the right or latest 32-bit pet version.
[edit 19/6/2015 - found 0.7.6 ran as desired in Frugal Slacko-5.9.3 so the non-appearance etc may be due to the 'oldness' of the Pups first tried with 0.7.6.]

So I will hold off doing any more with 0.7.6 for the present.

David S.

[Mike Walsh]

G'day, David.

"0.8 running well; why change?"

Absolutely.....couldn't agree more. It's all down to personal preference. I always liked the simpler interface of 0.7.6; I guess I probably got used to it, over the 12 months or so it was in use.

Just for your information, I went ahead and performed the change-over that I mentioned in my last post. I've now got all my 'Pups' running 0.7.6, sym-linked to the common 'bitmeter.db' file; as I suspected, it works flawlessly.

I appreciate that you're 'managing' more machines on your network than I am. I only have the two; the 'big' Compaq desktop, and the elderly Dell laptop....which doesn't get that much use, to be honest. It's just nice to know that she is there, ready to work & do all I ask of her, if & when I need to.

That said, I know I was initially saying, further back in the thread, about wanting to be able to measure network transfers as well as internet downloads.....but I'm not doing much in the way of LAN transfers in recent weeks. And 'bmsync' works perfectly with 0.7.6, too; no annoying episodes of non-starting. I'm probably going to stick with it, for now; but that's not to say I may not switch back to 0.8.0 at some point in the future. We'll see..!

I have the requisite software, and the knowledge & experience to swap things round, now. This is what I love about Linux.....it's much easier to set up stuff like this than I ever found to be the case with Windows.

I'm just pleased that other folk have showed an interest in not only using it, but also in developing it further, so as to make it more versatile, and even more usable...

I'll have a dig around, and see if I can locate that forum post for you. I can't remember which OS was referred to, either.....


Mike.

[Mike Walsh]

Just installed rg66's X-Slacko 2.3.2. I like XFCE.....always have. Have installed bitmeteros 0.8.0-all-32bit-pups .pet; working perfectly. First time I've tried the .pet with database installer; nicely clear, and very easy to use. Well done, Geoff!

Will add this to the OP 'working distros' list.


Regards,

Mike.