set the day of the month that months are expected to change

Registered by mekolat

This blueprint has been superseded. See the newer blueprint "Add an option for configuring which day a new month starts on." for updated plans.

see this: http://humdi.net/vnstat/man/vnstat.conf.html (MonthRotate)

currently, the only way of doing it is like this: (XX can be any number between 1 to 27)
sudo sed -i 's/MonthRotate 1/MonthRotate XX/g' /etc/vnstat.conf

for example, mine is set to 27 because my ISP is resetting the bandwidth counter every 27th of every month

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
lazyteq

Related branches

Sprints

Whiteboard

This is a planned feature (https://blueprints.launchpad.net/download-monitor/+spec/configurable-start-of-month).

As you have mentioned above, vnstat implements this - but I don't like the way
it is implemented. What vnstat does is read the system wide `/etc/vnstat.conf`
file and use that to determine how it records monthly usage in its database.

This has problems:

    - It means that to change this configuration, root access is required.
    IMO it is really bad user experience to require a password to modify a
    simple, minor setting like this.

    - It makes it very hard to test. I would literally have to wait months to
    see if it works properly because it changes the way the data is recorded
    not just how it is displayed. I can't just change the monthrotate value
    and see if download-monitor changes the display accordingly.

What should be done is the data usage should be recorded on an hourly basis
and just kept in the database like that. It should then be displayed based upon
the monthrotate value. i.e. this logic should go in the view, not the model.
This means that changes to the configuration display immediately, allowing rapid
testing and that the configuration can be stored on a per user basis, so root
access is not required to change it.

The solution is to write a custom monitor daemon. Luckily this isn't too
difficult - the daemon just needs to periodically parse /proc/net/dev.
Unfortunately, even though the app works fine, Download Monitor is so poorly
written (due to me learning while writing) that it isn't maintainable by any
sane human being and to enable such a feature requires a complete rewrite.
This isn't hard to do, but it will take some time.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.