freeradius not load clients.conf - freeradius

I am new in freeradius. I do not understand why radiusd does not take into account the clients.conf configuration file.
Extract from server logs :
-including configuration file /etc/freeradius/clients.conf
----------------------------------------------------------
--------------------
-radiusd: #### Loading Clients ####
- client localhost {
ipaddr = 127.0.0.1
require_message_authenticator = no
secret = <<< secret >>>
nas_type = "other"
proto = "*"
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
client localhost_ipv6 {
ipv6addr = ::1
require_message_authenticator = no
secret = <<< secret >>>
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
and my clients.conf in /etc/freeradius/ :
client dockernet
{
ipaddr = 172.17.0.0
secret = testing123
netmask = 24
shortname = dockernet
}

Ok , i am running freeradius with docker.
I am modifing the wrong config file

When FreeRADIUS starts up in debug mode, e.g.
radiusd -X
it prints out all the files it's reading. You need to run this to check that the file you are editing is the one actually being used.
Note that the configuration is often in different places depending on the installation.
Installed from source, the config is /usr/local/etc/raddb or /etc/raddb. On RedHat/CentOS based systems it's in /etc/raddb, and on Debian/Ubuntu systems it's in /etc/freeradius or /etc/freeradius/3.0.
For more advanced use cases, the -d option can tell FreeRADIUS to read its configuration from a different location, e.g.
radiusd -X -d /opt/raddb
This problem often comes about from having two installations, e.g. one installed from packages, and then installing from source on the same system.

Related

How to generate 100Mpps traffic of 64B packet size with Pktgen?

I tried to use dpdk-pktgen 3.7.2 with dpdk 18.11, but it only reached about 35 Mpps traffic with 64B packet size.Following is my lua script:
package.path = package.path ..";?.lua;test/?.lua;app/?.lua;../?.lua"
require "Pktgen";
local time = 30;
local pcnt_rate = 100;
sendport = 0;
recvport = 1;
pkt_size = 64;
burst_cnt = 128
local dstip = "192.168.100.100";
local srcip = "192.168.0.0";
function main()
pktgen.stop(sendport);
sleep(2);
pktgen.set(sendport, "size", burst_cnt);
pktgen.set(sendport, "burst", 64);
pktgen.set(sendport, "rate", pcnt_rate);
pktgen.set_ipaddr(sendport, "dst", dstip);
pktgen.set_ipaddr(sendport, "src", srcip);
pktgen.set_proto(sendport..","..recvport, "udp");
pktgen.start(sendport)
sleep(time)
pktgen.stop(sendport)
end
printf("\n**** Traffic Profile Rate for %d byte packets ***\n", pkt_size);
main();
printf("\n*** Traffic Profile Done (Total Time %d) ***\n", time);
l ran the script with the following command.
sudo pktgen -l 0-7 -n 4 -- -N -T -P -m "[1-7].0" -f script.lua
My NIC is Mellanox ConnectX-5 100GbE with traffic limit of 200Mpps and 100Gbps. Is there any problem in my script that restricts performance of pktgen? Thank you for your suggestions.
As mentioned in comments this is more of configuration issue of platform or not choosing right platform. I am able to generate 120Mpps with 64B on 100Gbps (CVL NIC).
[EDIT-2] Finally got hands on Mellanox connectx6 DX cards (2 *100Gbps). With DPDK 21.11 and PKTGEN 21.11, it is possible to generate over 100MPPs
MLX PMD args used: mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,txq_inline_mpw=128,rxq_pkt_pad_en=1
Platform Details:
DPDK:21.08
PKTGEN:pktgen-dpdk-pktgen-21.03.1
NIC:Ethernet Controller E810-C for QSFP
CPU: Intel(R) Xeon(R) Gold 6152 CPU # 2.10GHz
PKTGEN CMD:pktgen --legacy-mem -a 0000:86:00.0 -l 22-43 -- -P -m "[25-29:30-34].0" -N
[EDIT-1] #SoliRaven as mentioned in comments and answer one can generate up to 120 to 125 Mpps with Intel E810 & with Mellanox Connect6 DX 120MPPs. Hence this looks more like configuration, platform or firmware issues. Hence this is not DPDK or DPDK-PKTGEN is not issue.

How to monitor Apache Flume agents status?

I know the Enterprise (Cloudera for example) way, by using a CM (via browser) or by Cloudera REST API one can access monitoring and configuring facilities.
But how to schedule (run and rerun) flume agents livecycle, and monitor their running/failure status without CM? Are there such things in the Flume distribution?
Flume's JSON Reporting API can be used to monitor health and performance.
Link
I tried adding flume.monitoring.type/port to flume-ng on start. And it completely fits my needs.
Lets create a simple agent a1 for example. Which listens on localhost:44444 and logs to console as a sink:
# flume.conf
a1.sources = s1
a1.channels = c1
a1.sinks = d1
a1.sources.s1.channels = c1
a1.sources.s1.type = netcat
a1.sources.s1.bind = localhost
a1.sources.s1.port = 44444
a1.sinks.d1.channel = c1
a1.sinks.d1.type = logger
a1.channels.c1.type = memory
a1.channels.c1.capacity = 100
a1.channels.c1.transactionCapacity = 10
Run it with additional parameters flume.monitoring.type/port:
flume-ng agent -n a1 -c conf -f flume.conf -Dflume.root.logger=INFO,console -Dflume.monitoring.type=http -Dflume.monitoring.port=44123
And then monitor output in browser at localhost:44123/metrics
{"CHANNEL.c1":{"ChannelCapacity":"100","ChannelFillPercentage":"0.0","Type":"CHANNEL","EventTakeSuccessCount":"570448","ChannelSize":"0","EventTakeAttemptCount":"570573","StartTime":"1567002601836","EventPutAttemptCount":"570449","EventPutSuccessCount":"570448","StopTime":"0"}}
Just try some load:
dd if=/dev/urandom count=1024 bs=1024 | base64 | nc localhost 44444

How to get Task ID from within ECS container?

Hello I am interested in retrieving the Task ID from within inside a running container which lives inside of a EC2 host machine.
AWS ECS documentation states there is an environment variable ECS_CONTAINER_METADATA_FILE with the location of this data but will only be set/available if ECS_ENABLE_CONTAINER_METADATA variable is set to true upon cluster/EC2 instance creation. I don't see where this can be done in the aws console.
Also, the docs state that this can be done by setting this to true inside the host machine but would require to restart the docker agent.
Is there any other way to do this without having to go inside the EC2 to set this and restart the docker agent?
This doesn't work for newer Amazon ECS container versions anymore, and in fact it's now much simpler and also enabled by default. Please refer to this docu, but here's a TL;DR:
If you're using Amazon ECS container agent version 1.39.0 and higher, you can just do this inside the docker container:
curl -s "$ECS_CONTAINER_METADATA_URI_V4/task" \
| jq -r ".TaskARN" \
| cut -d "/" -f 3
Here's a list of container agent releases, but if you're using :latest – you're definitely fine.
The technique I'd use is to set the environment variable in the container definition.
If you're managing your tasks via Cloudformation, the relevant yaml looks like so:
Taskdef:
Type: AWS::ECS::TaskDefinition
Properties:
...
ContainerDefinitions:
- Name: some-name
...
Environment:
- Name: AWS_DEFAULT_REGION
Value: !Ref AWS::Region
- Name: ECS_ENABLE_CONTAINER_METADATA
Value: 'true'
This technique helps you keep everything straightforward and reproducible.
If you need metadata programmatically and don't have access to the metadata file, you can query the agent's metadata endpoint:
curl http://localhost:51678/v1/metadata
Note that if you're getting this information as a running task, you may not be able to connect to the loopback device, but you can connect to the EC2 instance's own IP address.
We set it with the so called user data, which are executed at the start of the machine. There are multiple ways to set it, for example: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-console
It could look like this:
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=ecs-staging
ECS_ENABLE_CONTAINER_METADATA=true
EOF
Important: Adjust the ECS_CLUSTER above to match your cluster name, otherwise the instance will not connect to that cluster.
Previous answers are correct, here is another way of doing this:
From the ec2 instance where container is running, run this command
curl http://localhost:51678/v1/tasks | python -mjson.tool |less
From the AWS ECS cli Documentation
Command:
aws ecs list-tasks --cluster default
Output:
{
"taskArns": [
"arn:aws:ecs:us-east-1:<aws_account_id>:task/0cc43cdb-3bee-4407-9c26-c0e6ea5bee84",
"arn:aws:ecs:us-east-1:<aws_account_id>:task/6b809ef6-c67e-4467-921f-ee261c15a0a1"
]
}
To list the tasks on a particular container instance
This example command lists the tasks of a specified container instance, using the container instance UUID as a filter.
Command:
aws ecs list-tasks --cluster default --container-instance f6bbb147-5370-4ace-8c73-c7181ded911f
Output:
{
"taskArns": [
"arn:aws:ecs:us-east-1:<aws_account_id>:task/0cc43cdb-3bee-4407-9c26-c0e6ea5bee84"
]
}
My ECS solution as bash and Python snippets. Logging calls are able to print for debug by piping to sys.stderr while print() is used to pass the value back to a shell script
#!/bin/bash
TASK_ID=$(python3.8 get_ecs_task_id.py)
echo "TASK_ID: ${TASK_ID}"
Python script - get_ecs_task_id.py
import json
import logging
import os
import sys
import requests
# logging configuration
# file_handler = logging.FileHandler(filename='tmp.log')
# redirecting to stderr so I can pass back extracted task id in STDOUT
stdout_handler = logging.StreamHandler(stream=sys.stderr)
# handlers = [file_handler, stdout_handler]
handlers = [stdout_handler]
logging.basicConfig(
level=logging.INFO,
format="[%(asctime)s] {%(filename)s:%(lineno)d} %(levelname)s - %(message)s",
handlers=handlers,
datefmt="%Y-%m-%d %H:%M:%S",
)
logger = logging.getLogger(__name__)
def get_ecs_task_id(host):
path = "/task"
url = host + path
headers = {"Content-Type": "application/json"}
r = requests.get(url, headers=headers)
logger.debug(f"r: {r}")
d_r = json.loads(r.text)
logger.debug(d_r)
ecs_task_arn = d_r["TaskARN"]
ecs_task_id = ecs_task_arn.split("/")[2]
return ecs_task_id
def main():
logger.debug("Extracting task ID from $ECS_CONTAINER_METADATA_URI_V4")
logger.debug("Inside get_ecs_task_id.py, redirecting logs to stderr")
logger.debug("so that I can pass the task id back in STDOUT")
host = os.environ["ECS_CONTAINER_METADATA_URI_V4"]
ecs_task_id = get_ecs_task_id(host)
# This print statement passes the string back to the bash wrapper, don't remove
logger.debug(ecs_task_id)
print(ecs_task_id)
if __name__ == "__main__":
main()

Connect to MSSQL via ODBC with FreeTDS

I am working with a group who needs to access a MSSQL db from a linux host and in my searching found FreeTDS, which i am able to connect with FreeTDS but our programmer states that ODBC will require to configured with FreeTDS for their PHP code to work. With that being said, i have tried configuring both unixODBC and unixODBC_23 for the past day and have been unsuccesful in finding a config that works properly and I am also not able to get tracing working either. So, without further ado, here is my config
--- odbc.ini and odbc_23.ini ---
[TC]
Description = FreeTDS Connection
Driver = FreeTDS
Database = mydb
ServerName = 192.168.1.12
TDS_Version = 7.0
PORT = 3433
[Default]
Driver = /usr/local/freetds-0.91/lib/libtdsodbc.so
---odbcinst.ini and odbcinst_23.ini---
[FreeTDS]
Description = FreeTDS
Driver = /usr/local/freetds-0.91/lib/libtdsodbc.so
Trace = 1
TraceFile = /tmp/freetds.log
UsageCount = 1
When i try connecting via isql, here is what i receive.
root#host(~)# isql_23 -v TC myuser mydb
[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source
[01000][unixODBC][FreeTDS][SQL Server]Unknown host machine name.
[ISQL]ERROR: Could not SQLConnect
root#host(~)#
Any ideas would be greatly appreciated!
Try Server instead of ServerName?
Server = 192.168.1.12
Ok, so there was one additional change that i had to make in addition to changing "ServerName" to "Server" and that was I removed "Database = mydb" and moved it to the "Server" and now my file looks like so:
[TC]
Description = FreeTDS
Driver = FreeTDS
Server = 192.168.1.12\mydb
TDS_Version = 7.0
PORT = 3433
and now im connected with this command:
root#host(~)# isql_23 -v TC user password
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> ^C
root#host(~)#

SQL Server and Rails trouble

note: this is a repost. This question was previously deleted for undisclosed reasons
Ok, I've been trying to get this to work like all day now and I'm barely any further from when I started.
I'm trying to get Ruby On Rails to connect to SQL Server. I've installed unixODBC and configured it and FreeTDS and installed just about every Ruby gem relating to ODBC that exists.
(This has been updated to show the output of isql with -v)
[earlz#earlzarch myproject]$ tsql -S AVP1 -U sa -P pass
locale is "en_US.UTF-8"
locale charset is "UTF-8"
1> quit
[earlz#earlzarch ~]$ isql -v AVP1 sa pass
[IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified
[ISQL]ERROR: Could not SQLConnect
[earlz#earlzarch myproject]$ rake db:version
(in /home/earlz/myproject)
rake aborted!
IM002 (0) [unixODBC][Driver Manager]Data source name not found, and no default driver specified
(See full trace by running task with --trace)
so, as you can see, tsql works, but not isql. What is the difference in the two that breaks it?
/etc/odbc.ini
[AVP1]
Description = ODBC connection via FreeTDS
Driver = TDS
Servername = my.server
UID = sa
PWD = pass
port = 1232
Database = mydatabase
/etc/odbcinst.ini
[TDS]
Description = v0.6 with protocol v7.0
Driver = /usr/lib/libtdsodbc.so
Setup = /usr/lib/libtdsS.so
CPTimeout =
CPReuse =
FileUsage = 1
(and yes, I've made sure that the .so files exist)
the relevant part in freetds.conf
[AVP1]
host = my.server
port = 1232
tds version = 8.0
and finally, my database.yml
development:
adapter: sqlserver
mode: odbc
dsn: AVP1
username: sa
password: pass
Can anyone please help me before I pull all my hair out?
I am using a 64 bit Arch Linux that is completely up to date.
What could be causing isql to fail. I've tried every solution I've seen so far for this problem but none of them are actually working for me. Do I have to recompile FreeTDS or something?
Ok, I have also verified with strace that it is finding the configuration file, as shown by this excerpt:
open("/etc/odbc.ini", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=159, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc71fe09000
read(3, "[AVP1]\n Description = ODBC "..., 4096) = 159
If anyone has gotten tsql to work but has searched far and wide on the Internet and has troubleshooted their configs and still has not been able to get isql to work check your server logs.
I have been troubleshooting a Xubuntu 12.04 unixodbc install and config for a week now and tried everything possible to get it fixed when I decided to check my windows server event viewer to see what was happening when the request was coming into the server or if a request was even coming into the server and discovered that the problem was that I couldn't get into a specific database. I was able to get into SQL Server ok but not the actual DB I had listed in my odbc.ini file.
Here is the specific text in the event log "Login failed for user 'ePMX'.
Reason: Failed to open the explicitly specified database. [CLIENT:
192.168.27.25]".
What sparked my interest was the word "explicit". So I simply commented out the Database = <DB Name> and suddenly everything worked and I got the SQL prompt after untold hours of researching and trying everything possible.
So if you are having trouble using unixodbc don't forget to troubleshoot the server side of things as well the client side because I have seen tons of posts where people had the exact same problem I was having but there was never any response to how to resolve it so I am guessing that a large number of the people that were having the issue were Server side issues.
For a great troubleshooting tool use osql rather than isql(osql actually in fact uses isql to connect) because it will go through the connection process step by step and give you details about where the failure occurs. It is used the same way you use isql:
osql <DSN> <user> <password>.
So as I said be sure to check your server logs if you have tried everything else and have been unable to figure out what the problem is.
Ok, I finally figured it out after only 2 straight days of banging my head against the wall.
I'll try to give as much info as possible so that if someone finds this in the same situation I was in, they'll find this useful.
[earlz#earlzarch ~]$ cat /etc/odbc.ini
[AVP1]
Description=ODBC connection via FreeTDS
Driver=/usr/lib/libtdsodbc.so
Server=192.168.0.100
UID=sa
PWD=pass
Port=1232
ReadOnly=No
[earlz#earlzarch ~]$ cat /etc/odbcinst.ini
[TDS]
Description = v0.60 with protocol v7.0
Driver = /usr/lib/libtdsodbc.so
Driver64 = /usr/lib
Setup = /usr/lib/libtdsS.so
Setup64 = /usr/lib
CPTimeout =
CPReuse =
FileUsage = 1
[earlz#earlzarch ~]$ cat /etc/freetds/freetds.conf
[global]
tds version = 8.0
initial block size = 512
swap broken dates = no
swap broken money = no
try server login = yes
try domain login = no
cross domain login = no
# If you get out-of-memory errors, it may mean that your client
# is trying to allocate a huge buffer for a TEXT field.
# Try setting 'text size' to a more reasonable limit
text size = 64512
[TDS]
host = 192.168.0.100
port = 1232
tds version = 8.0
and if your lucky, after that:
[earlz#earlzarch ~]$ isql -v AVP1
[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source
[01000][unixODBC][FreeTDS][SQL Server]Adaptive Server connection failed
[ISQL]ERROR: Could not SQLConnect
[earlz#earlzarch ~]$ isql -v AVP1 sa pass
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL>
I did not have to set any kind of environmental variables and I didn't have to manually compile anything either with Arch Linux 64bit (date April 7th, 2010). After getting isql to work, Rails immediately connected to the database also. Now I just have to figure out why db:schema:load isn't working, but thats another question :)
Also, notice the only real difference between this set of files and the last is in /etc/odbc.ini I set the Driver field to be the actual file name of a driver rather than named for some configuration entry.
When building FreeTDS, current versions of SQL Server need TDS protocol v8 (http://www.freetds.org/userguide/config.htm):
./configure --with-tdsver=8.0 --enable-msdblib

Resources