BIT METER OS 0.7.6 (stable) & 0.8.0 (experimental)
-
gcmartin
Not necessarily. If all parties contributed to the common db, then it should be a reasonably close report.amigo wrote:To be able to measure and control the traffic from one computer, then it would need to be the gateway for the others so that all traffic got routed through it.
I do agree, though, that this function is best suited for the gateway. But, most home users do NOT have the ability to modify their gateway.
And, @Amigo, I think, is exhibiting concerns for things other than PCs, and those without BM, which also use the Gateway to get out through the ISP's data on-ramp. Centralizing the function in a Gateway is entirely reasonable if we could insert this kind of logic into the central Gateway device(s).
@Rcrsn51 does have a codebase for using an old motherboard to be an Internet Gateway, where this utility function could be centralized. Its availability is restricted: As he has chosen to NOT make it publicly available. When a Gateway subsystem does become generally available, unrestricted, using the traditional PUPPY channels, I believe this community will respond with PUP distro(s) which could replace vendor/ISP/Telco Gateway devices. This is just one more of the kind of Home services that PUPs can do in the Home LAN/WAN for members benefit.
For this thread, though, BM does offers reports which can be useful, taken into context.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@gcm:-
Now then.....
Managed to find time this evening to try this out. All my Pups on the 'big' Compaq are running 0.8.0 as a matter of course. I've had 0.8.0 running on the Dell laptop for the last few weeks. Since I use the Dell as a Samba client to access files through Samba-TNG from the Compaq & various drives which I have attached to it, the LAN data reporting comes in very handy.
I did the following:-
1) Set up the Common Data partition as a Samba share.
2) Opened /var/lib/bitmeter; deleted 'bitmeter.db'; sym-linked the main 'bitmeter.db' file from the Common Data 'share' across to /var/lib/bitmeter to take its place.
3) Edited 'xbitmeter' as necessary.
4) Did a terminal restart of '/etc/init.d/bitmeter' & '/etc/init.d/bitmeterweb' to get the daemons up-and-running again.
5) Went into Chromium (which is my main browser these days
), and opened the web interface. And.....
Well; it sorta works. The app opens, as it should. There is a readout...of sorts. But to put it in a nutshell, the P4 in the Dell isn't man enough to keep up with the demands of remote monitoring/writing. It runs pretty near flat-out, more-or-less continuously (in the process generating a constant error message along the lines of 'The server is taking a long time to respond. This can be due to high CPU load, or slow data transfer across the network' (or something similiar))...
Essentially, it's so busy coping with BitMeter's demands, that it leaves next to no juice to run the OS/apps. It's so sluggish, it's unusable. Kinda reminds me of a few years ago, when she was running XP, and it was time for the SP3 update ( and this was before I'd uprated the old Celeron to the P4)... From recollection, I think it took nearly all night to download and install; that was slow..!
So; since I don't use her that much, I've just set the alerts to a combined 20 GB total for the month; 3 GB on the Dell, and 17 GB for the rest of the litter on the Compaq. Should work out about right.
Good idea in theory; but it needs more horsepower than I've got. A modern dual- or quad-core CPU (with SSE3's; my earlier generation P4 only has SSE2's), and some additional RAM, would, I feel, make a world of difference. Unfortunately, neither of those is a viable proposition with the Dell, since she's maxed out in both of those departments!
I'm not complaining, mind. 'Puppy' resurrected the old girl from almost certain extinction; I think I can live without using BM-OS the way I hoped to.....
Regards,
Mike.
Now then.....
Managed to find time this evening to try this out. All my Pups on the 'big' Compaq are running 0.8.0 as a matter of course. I've had 0.8.0 running on the Dell laptop for the last few weeks. Since I use the Dell as a Samba client to access files through Samba-TNG from the Compaq & various drives which I have attached to it, the LAN data reporting comes in very handy.
I did the following:-
1) Set up the Common Data partition as a Samba share.
2) Opened /var/lib/bitmeter; deleted 'bitmeter.db'; sym-linked the main 'bitmeter.db' file from the Common Data 'share' across to /var/lib/bitmeter to take its place.
3) Edited 'xbitmeter' as necessary.
4) Did a terminal restart of '/etc/init.d/bitmeter' & '/etc/init.d/bitmeterweb' to get the daemons up-and-running again.
5) Went into Chromium (which is my main browser these days
), and opened the web interface. And.....Well; it sorta works. The app opens, as it should. There is a readout...of sorts. But to put it in a nutshell, the P4 in the Dell isn't man enough to keep up with the demands of remote monitoring/writing. It runs pretty near flat-out, more-or-less continuously (in the process generating a constant error message along the lines of 'The server is taking a long time to respond. This can be due to high CPU load, or slow data transfer across the network' (or something similiar))...
Essentially, it's so busy coping with BitMeter's demands, that it leaves next to no juice to run the OS/apps. It's so sluggish, it's unusable. Kinda reminds me of a few years ago, when she was running XP, and it was time for the SP3 update ( and this was before I'd uprated the old Celeron to the P4)... From recollection, I think it took nearly all night to download and install; that was slow..!
So; since I don't use her that much, I've just set the alerts to a combined 20 GB total for the month; 3 GB on the Dell, and 17 GB for the rest of the litter on the Compaq. Should work out about right.
Good idea in theory; but it needs more horsepower than I've got. A modern dual- or quad-core CPU (with SSE3's; my earlier generation P4 only has SSE2's), and some additional RAM, would, I feel, make a world of difference. Unfortunately, neither of those is a viable proposition with the Dell, since she's maxed out in both of those departments!
I'm not complaining, mind. 'Puppy' resurrected the old girl from almost certain extinction; I think I can live without using BM-OS the way I hoped to.....
Regards,
Mike.
Last edited by Mike Walsh on Sun 07 Jun 2015, 11:23, edited 3 times in total.
Copy the db file for occasional use
G'day Mike,
If I understand your experience with the elderly laptop using Bitmeter through the network server (Samba), that it is the frequent writing to the network that slows things down, what about taking the latest up-to-date copy of the .db file from your data drive and using that copy somewhere on the laptop when starting Bitmeter on the laptop.
Just before closing down the elderly laptop, copy the now bigger .db file back to your network data partition in place of the original. The new file would then become that for the next use.
May work for a single-network-user at-any-one-time situation, but not when two computers are on the internet together. And require a disciplined user.
Can the history of two or more Bitmeter records be merged 'off-line' as a means to aggregate a multi-computer situation?
Probable answer: yes - use the bmsync program? Will try with some of the networked desktops; if that works, could then try with the Windows7 laptop that wifis to the home network.
David S.
If I understand your experience with the elderly laptop using Bitmeter through the network server (Samba), that it is the frequent writing to the network that slows things down, what about taking the latest up-to-date copy of the .db file from your data drive and using that copy somewhere on the laptop when starting Bitmeter on the laptop.
Just before closing down the elderly laptop, copy the now bigger .db file back to your network data partition in place of the original. The new file would then become that for the next use.
May work for a single-network-user at-any-one-time situation, but not when two computers are on the internet together. And require a disciplined user.
Can the history of two or more Bitmeter records be merged 'off-line' as a means to aggregate a multi-computer situation?
Probable answer: yes - use the bmsync program? Will try with some of the networked desktops; if that works, could then try with the Windows7 laptop that wifis to the home network.
David S.
Last edited by davids45 on Mon 08 Jun 2015, 23:49, edited 1 time in total.
-
gcmartin
Request
If I understand correctly, you already have a Compaq desktop with BM's db shared out from that desktop. Which means that any of your LAN's PCs, including your Dell laptop is able to access that share thru a mere "mount command"; for example
So, I offer this idea, all to be done on your Dell laptop where you experienced out of control CPU utilization:
Please share your TOP/HTOP utilization.
P.S. Although, I'm sure you wont need a mount example, I offer for your DELL Laptop's connection to your Compaq's db:You know the rest for symbolic db on the Laptop to the physical file
If I understand correctly, you already have a Compaq desktop with BM's db shared out from that desktop. Which means that any of your LAN's PCs, including your Dell laptop is able to access that share thru a mere "mount command"; for example
Code: Select all
# mount -t cifs //CompaqDesktopIPaddress/SharedBMfolder /mnt/4localBMacc - Boot your laptop pristine (ie. pfix=ram)
- After FirstRUN, issue the above mount with your local namings
- Do NOT run ANY NETWORK UTILITIES for any other kind of network sharing! (the above command is all that is needed)
- Install BM
- Set BM db path appropriate to where you mounted the above
- Open your browser to URL "localhost:2605" to see dataflows
Please share your TOP/HTOP utilization.
P.S. Although, I'm sure you wont need a mount example, I offer for your DELL Laptop's connection to your Compaq's db:
Code: Select all
# mkdir /mnt/Access2BM-DB
# mount -t cifs //192.168.1.2/BM-DB /mnt/Access2BM-DBAccessing the file from multiple comps is not going to work as file locks will prevent it from being accessed when it is already being accessed.
GC, you always talk about how Puppy should fit in -of all the possibilities for control etc. Nearly always, what you are describing is simply that puppy should be the gateway (or router) for other devices. There is nothing new or revolutionary about it. Your router is running a small linux and you could certainly flash a new system onto the router, or simply insert your puppy where your router was.
GC, you always talk about how Puppy should fit in -of all the possibilities for control etc. Nearly always, what you are describing is simply that puppy should be the gateway (or router) for other devices. There is nothing new or revolutionary about it. Your router is running a small linux and you could certainly flash a new system onto the router, or simply insert your puppy where your router was.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
G'day, David.
I've been having a think about this. Certainly your idea is viable (and as you say, would require quite a bit of discipline on my part!); the more so after last night, since upon re-reading rcrsn51's Samba-TNG thread, I've now realised why the Dell could only read from the Compaq, and not write to it...
Needed some different commands in 'smb.conf'. Changed:-
To:-
.....and I can now read/write in both directions. So, yes; for the few occasions on which I use the Dell, yours is actually quite a practical suggestion.
@amigo:- You could well be correct about the 'file lock'; I certainly won't dispute that, since I'm still fairly new to Linux...
--------------------------------------------------------------------------------------------------------
I've been thinking that the main reason, probably, that the P4 is running flat-out is in all likelihood due to the frequency of the 'Refresh Intervals' (set via the BitMeter 'Preferences' tab). From a 'virgin' install of Bitmeter, they read as follows:-
Monitor updates every 1 second.
History updates every 10 seconds.
Summary updates every 10 seconds.
Alerts updates every 10 seconds.
I think that the Monitor tab refresh interval is the culprit. Once every second..! I don't actually use the 'Monitor' tab at all.....nor the 'History' tab. The two that I'm interested in are the 'Summary' and 'Alert' tabs. I don't for a moment believe that it's the Samba connection itself, since when I'm on the Dell, the Compaq's 'Pupshare' is one of the first things I open; it stays open for the duration of the session, and CPU usage is almost always what you'd expect it to be; perfectly average.
So; later on today, I'm going to repeat last night's experiment, and make some adjustments to the refresh intervals. Of course, my reasoning could be fallacious.....but I've a feeling that's somewhere near the root of the problem.
Will let y'all know what happens. Watch this space.....
Regards,
Mike.
I've been having a think about this. Certainly your idea is viable (and as you say, would require quite a bit of discipline on my part!); the more so after last night, since upon re-reading rcrsn51's Samba-TNG thread, I've now realised why the Dell could only read from the Compaq, and not write to it...
Needed some different commands in 'smb.conf'. Changed:-
Code: Select all
[Pupshare]
path = /root
writable = yesCode: Select all
[Pupshare]
path = /root
guest ok = yes
writable = yes
force user = root.....and I can now read/write in both directions. So, yes; for the few occasions on which I use the Dell, yours is actually quite a practical suggestion.
@amigo:- You could well be correct about the 'file lock'; I certainly won't dispute that, since I'm still fairly new to Linux...
--------------------------------------------------------------------------------------------------------
I've been thinking that the main reason, probably, that the P4 is running flat-out is in all likelihood due to the frequency of the 'Refresh Intervals' (set via the BitMeter 'Preferences' tab). From a 'virgin' install of Bitmeter, they read as follows:-
Monitor updates every 1 second.
History updates every 10 seconds.
Summary updates every 10 seconds.
Alerts updates every 10 seconds.
I think that the Monitor tab refresh interval is the culprit. Once every second..! I don't actually use the 'Monitor' tab at all.....nor the 'History' tab. The two that I'm interested in are the 'Summary' and 'Alert' tabs. I don't for a moment believe that it's the Samba connection itself, since when I'm on the Dell, the Compaq's 'Pupshare' is one of the first things I open; it stays open for the duration of the session, and CPU usage is almost always what you'd expect it to be; perfectly average.
So; later on today, I'm going to repeat last night's experiment, and make some adjustments to the refresh intervals. Of course, my reasoning could be fallacious.....but I've a feeling that's somewhere near the root of the problem.
Will let y'all know what happens. Watch this space.....
Regards,
Mike.
Last edited by Mike Walsh on Sun 07 Jun 2015, 17:25, edited 2 times in total.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
I'm inclined to think amigo is right about the file-locking.
By the very nature of the way we have this set-up, whichever Puppy I happen to be running, BitMeter is set to start automatically, and to use the sym-linked remote main BitMeter database as it does so.
This means, of course, that whenever I attempt to use the Dell at the same time, I have at least two BM-OS installs attempting to write to the main database simultaneously. If amigo is correct (and I'm inclined to think that he/she is ), then the 'file-lock' will prevent the secondary 'write' from occurring.
Having repeated the experiment with the monitor refresh interval increased to '10', the same as the others, the CPU usage is now far more reasonable. Observing pWidgets' CPU graph (which I use), instead of solid 100% usage, I now merely get a nice little 'spike' every 10 seconds or so.....which is what I would expect. (See attachment).
BUT; the database is very obviously not being updated. So...
This leaves two possibilities. Either David's suggestion.....to use a copy of the main 'bitmeter.db' file for the duration of each session on the Dell, and then to write it back at the end of the session; or, which I'm inclined to think would also work, to switch off the bmcapture daemon manually on the Compaq when I want to use the Dell, so that only the Dell is, at that point, writing to the database.
Both of these mean manual intervention. Be nice if I could automate the process, but as I know absolutely nothing about scripting, this means relying on someone else to do this for me.....which is, I feel, asking a bit much!
Even David's suggestion would, if amigo is correct, mean briefly switching off the bmcapture daemon while the database was being updated.
What to do...and how to do it? Hmmm.....
*thinks*
EDIT; I'm going to pose a question now. Is it possible, via Samba, to remotely open a terminal in 'Pupshare', using Rox (right-click in the Rox-filer window, and 'Terminal here')? If so, then I could switch off the Compaq's BitMeter daemons from the Dell.....so at least I could do things all from one end. Is that possible? Is my intention clear, what I want to do?
Regards,
Mike.
By the very nature of the way we have this set-up, whichever Puppy I happen to be running, BitMeter is set to start automatically, and to use the sym-linked remote main BitMeter database as it does so.
This means, of course, that whenever I attempt to use the Dell at the same time, I have at least two BM-OS installs attempting to write to the main database simultaneously. If amigo is correct (and I'm inclined to think that he/she is ), then the 'file-lock' will prevent the secondary 'write' from occurring.
Having repeated the experiment with the monitor refresh interval increased to '10', the same as the others, the CPU usage is now far more reasonable. Observing pWidgets' CPU graph (which I use), instead of solid 100% usage, I now merely get a nice little 'spike' every 10 seconds or so.....which is what I would expect. (See attachment).
BUT; the database is very obviously not being updated. So...
This leaves two possibilities. Either David's suggestion.....to use a copy of the main 'bitmeter.db' file for the duration of each session on the Dell, and then to write it back at the end of the session; or, which I'm inclined to think would also work, to switch off the bmcapture daemon manually on the Compaq when I want to use the Dell, so that only the Dell is, at that point, writing to the database.
Both of these mean manual intervention. Be nice if I could automate the process, but as I know absolutely nothing about scripting, this means relying on someone else to do this for me.....which is, I feel, asking a bit much!
Even David's suggestion would, if amigo is correct, mean briefly switching off the bmcapture daemon while the database was being updated.
What to do...and how to do it? Hmmm.....
*thinks*
EDIT; I'm going to pose a question now. Is it possible, via Samba, to remotely open a terminal in 'Pupshare', using Rox (right-click in the Rox-filer window, and 'Terminal here')? If so, then I could switch off the Compaq's BitMeter daemons from the Dell.....so at least I could do things all from one end. Is that possible? Is my intention clear, what I want to do?
Regards,
Mike.
- Attachments
-
- BitMeter CPU usage.jpg
- 'Spike' every 10 seconds...
- (40.56 KiB) Downloaded 334 times
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
These various BitMeter .pets are now mirrored at filehosting.org.....you can never have too much backup! Links are as follows:-
The original two:-
0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.pet
0.8.0 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.pet
The latest versions, for those of us who want to run BitMeter on multiple Puppies & get a monthly aggregate total. This one will ask you where, & how you want to set up a common shared database:-
0.7.6 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet
0.8.0 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet
And the original four .debs, from Rob Dawson's CodeBox website. I've included these, because some people have found that the .deb works for them, rather than the .pet:-
0.7.6 for 32-bit:- http://www.filehosting.org/file/details ... 6-i386.deb
0.7.6 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.deb
0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.deb
0.8.0 for 64-bit:- [url]http://www.filehosting.org/file/details ... 64.deb[url]
Regards,
Mike.
The original two:-
0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.pet
0.8.0 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.pet
The latest versions, for those of us who want to run BitMeter on multiple Puppies & get a monthly aggregate total. This one will ask you where, & how you want to set up a common shared database:-
0.7.6 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet
0.8.0 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet
And the original four .debs, from Rob Dawson's CodeBox website. I've included these, because some people have found that the .deb works for them, rather than the .pet:-
0.7.6 for 32-bit:- http://www.filehosting.org/file/details ... 6-i386.deb
0.7.6 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.deb
0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.deb
0.8.0 for 64-bit:- [url]http://www.filehosting.org/file/details ... 64.deb[url]
Regards,
Mike.
Last edited by Mike Walsh on Mon 08 Jun 2015, 18:51, edited 1 time in total.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
Hi, amigo.
That's basically what the 'bmsync' facility on the 'CodeBox' website does:-
http://codebox.org.uk/pages/bitmeteros/bmsync/man
However, I've yet to be able to persuade this to work! It may be a firewall issue.....although I've tried running 'bmsync' without the firewall running, and it still won't play ball.
I'm probably making a basic mistake somewhere along the line, although for the life of me, I can't think what I'm doing wrong...
Regards,
Mike.
That's basically what the 'bmsync' facility on the 'CodeBox' website does:-
http://codebox.org.uk/pages/bitmeteros/bmsync/man
However, I've yet to be able to persuade this to work! It may be a firewall issue.....although I've tried running 'bmsync' without the firewall running, and it still won't play ball.
I'm probably making a basic mistake somewhere along the line, although for the life of me, I can't think what I'm doing wrong...
Regards,
Mike.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
**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.
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.
Last edited by Mike Walsh on Wed 08 Jul 2015, 15:44, edited 3 times in total.
Synchronise other network computer downloads
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.
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.
- Attachments
-
- bmsync150610.jpg
- terminal responses when trying bmsync to other computer
- (98.41 KiB) Downloaded 301 times
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
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.
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.
bmsync - needs bmdb start on 'other' computer
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
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.
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
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).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.
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.
- Attachments
-
- bitmetersynced150611.jpg
- Bitmeter main summary after successful bmsync - compare with previous post screenshot.
- (84.7 KiB) Downloaded 271 times
-
gcmartin
One explanation of the steps to follow for setup on the LAN
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
Open a terminal and enter the followingYou 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)
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 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)
Open a terminal and enter the following
Code: Select all
# bmdb webremote
# bmdb webstop
# bmdb webstart
# ip addrOn 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
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.
Last edited by gcmartin on Thu 11 Jun 2015, 07:30, edited 5 times in total.
bmdb stop-start commands - on each 'client' computer
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.
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.
bmsync - extra 3 computers now hosted
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.
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.
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.
- Attachments
-
- bm_synced_4computers.jpg
- Four computer BM Summary - first group the main computer, three below bmsynced as hosts
- (99.42 KiB) Downloaded 268 times
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
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.
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
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
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.
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.