I have freeradius server installed on centos 6 with MySQL and Mikrotik as a controller.
I want to restrict the user to use internet according to billing plan like use internet for 1 hour in 3 days. After 3 days the same username should get again 1 hour for next 3 days.
Please suggest which modification should I need to do in radius configuration and which parameters should I send.
A Session-Time attribute will set the maximum time a session may take. This does not account for other rules like a maximum time over a day or a week. You need more logic for this than an attribute in your RADIUS reply.
A stateful storage is needed to keep track of the used time for a user. RADIUS accounting is sufficient for this purpose. For example, when storing accounting data in MySQL you can query the already used session time for a period to calculate a new Session-Time for the upcoming session.
You can use Radclient to disconnect sessions in Mikrotik.
FreeRADIUS has modules for this purpose: sqlcounter and counter. The documentation covers examples of implementation.
Related
I want to get the license assignment time for each license assigned to each user in a tenant. Using the audit logs I'm able to fetch this data but its partial in nature as the audit logs are retained for 30 days by default, so I can't get the time of license assignment if it happened before this 30 day period.
Is there any other workaround for this using the Graph API only, where I can get the information about license assignment time for each user and their assigned licenses irrelevant of the assignment period
https://graph.microsoft.com/beta/users?$select=id,displayName,assignedLicenses,assignedPlans
In this above query, you get the data of assigned licenses, assigned plans of the user, and their assignedDateTime, but currently, you cann't filter assignedplans by graph api needs to handle through code (in general, only those properties where the documentation says "supports $filter" can be filtered). So you can raise the UserVoice if you want to $filter to support assigned plan
Consider this scenario in ThingsBoard, default installation, single server:
There is only one device (for sake of simplicity) configured called "device_name", authenticated via token "device_token", no password. It already communicates successfully via MQTT with ThingsBoard and I already set up a small, working dashboard with a gauge and controls attached to the methods described below:
read_sensor, returns value from internal sensor (let's say, for example, ambient light); Not directly relevant to the question, included to make the scenario clear.
activate, turns on internal relay (controls lights, for example) and sets internal variable status to "on". Returns this variable.
deactivate, turns off internal relay and sets internal variable status to "off". Returns this variable.
toggle, turns internal relay on or off depending on previous value of the status variable based on "not" operation. Sets the status
variable to the opposite of previous value and returns it.
The question is "how do I call the methods activate and deactivate at specific dates/times (server time) of the day using ThingsBoard rules and plugins?"
Examples:
Call activate after 18:00 every weekday from monday to friday, but
not on saturdays and sundays.
Call deactivate after 08:00 every weekday from monday to friday,
but not on weekends.
I already set up and configured the Time, Telemetry and RPC system plugins.
There is an alternate configuration of the device with an extra method change(status) that turns on or off the relay based on the status provided, sets the internal variable to the value provided and returns it.
In the Thingsboard Professional Edition there is an action node "generator" that you can link to the PE feature "Scheduler". Within the scheduler it is possible to define an event being created according to a daily or weekly schedule.
For your application there would be two separate timers necessary for activation and deactivation. The events created must the be linked to a generator in your rule chain to trigger method execution.
We're using ejabberd as our xmpp server and iphone xmppframework for client side.
The problem is when we get the offline messages the timestap that is written in the message is in actual date/time format but the timezone of the server is different than the clients time zones so at this point the things are getting messy.
We're using a same approach while querying Last Activity of a user(XEP-0012) , but in last activity xep the server returns the information as "how many seconds ago the user last logged in to server" so in this way we can apply seconds difference to our clients time and found the message delivery date/time so there is no problem in Last Activity query.
But in delayed delivery , ejabberd sends an exact date and time value and clients confuses about the conversion(Date and time of each client may be very different from each others)
Does anyone know how can we fix that problem? Is there any way to configure ejabberd to return "seconds passed information" until offline message send ?
By the way we're using latest ejabberd version.
Thanks
XEP-0091 (Legacy Delayed Delivery) says:
The timezone is be understood as UTC.
So you need to convert the time from UTC to the local time of the client in order to get the correct result.
The newer specification, XEP-0203 (Delayed Delivery) also says:
[...] MUST be expressed in UTC
I am working on a project that requires an automated SSIS package to
connect to SurveyMonkey data store via API to incrementally download survey
results for the day or specified time period for custom reporting and low scoring task assignment.
Via OAuth I can collect a long lived access token, but due to the automated
and infinite nature of my projects lifespan, I cannot manually initiate
OAuth2 token refreshes or complete manual re-authentication cycles.
Is there another method to automatically export this data upon a scheduled
request?
Additionally, for clarification for how long is a long lived access token
valid? 60 days?
Miles from surveymonkey.com support responded to me with a great answer. I hope it can help someone down the line.
Hi Rob,
Currently our tokens should not expire - this is not guaranteed and
may change in future, but we will send out an update well ahead of
time if this does ever change. The token you receive on completion of
OAuth lets you know how long the token will last for without user
intervention, currently it returns 'null' in the 'expires_in' field.
There is no other automated way to schedule the data to be exported
currently, however it sounds like our current setup should suit your
needs
In addition to Miles's reply, it is very straightforward to pull diffs from surveymonkey using modified dates. we keep "last sync" timestamp per-survey in our database, and update it after each successful data pull.
Use the REST api directly, or (if you're using PHP) try https://github.com/oori/php-surveymonkey. We run it in production.
*note: actually, you're interested in setting the start_modified_date option for the "getRespondentList" function. but in general - see the API docs, modified date filter is available in more functions.
Our experiments have shown that GMail does not use UTC for the internal dates in its mailstore. Anyone know what offset it uses? We've narrowed it to between 3 and 7 hours behind UTC (exclusive), and we could figure it out with further experimentation, but maybe someone knows off-hand. UID SEARCH and the like aren't very accurate if you are assuming UTC and it's not the case. :-)
Further, we're wondering if it's consistent regardless of where you're connecting to gmail in the world.
Update: the first test showed UTC-4 or UTC-5, and a second test I did (sending hourly emails) revealed my account to be UTC-7. We're wondering if it's set when you register depending on your source IP (I also registered an account with a UTC-10 timezone and the internal store was still UTC-7. And changing your account timezone later doesn't change the internal store date an IMAP client sees, wisely, I would think).
I had written a python IMAP lib client and confirmed that the Gmail timezone is UTC-07:00 and I have confirmed it over and over again. So, any search results that you obtain (more precisely the after: startDate and before: endDate query) are shifted by that much amount according to your local timezone. This is because the mailstore uses the local time according to the sender SMTP server, which in case of gmail happens to be at UTC-07:00.