LXD container: What does apparmor mount error -13 mean? - lxd

I have PiHole inside LXD container (on Ubuntu Server). It works very well, but I can see plenty of such errors in server's dmesg:
audit: type=1400 audit(1613833741.169:605): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-pihole2_</var/snap/lxd/common/lxd>" name="/run/systemd/unit-root/bin/" pid=3219245 comm="(ionclean)" flags="ro, remount, noatime, bind"
What can I do with it?

Related

Datadog agent do not send data

I run into an issue with my Datadog agent. I installed Agent version 7.35.0 on an EC2 ubuntu machine. After I restarted the agent I got this error:
Apr 10 11:24:24 ip-10-100-0-33 agent[9951]: 2022-04-10 11:24:24 UTC | CORE | WARN |(pkg/collector/python/datadog_agent.go:124 in LogMessage) | disk:e5dffb8bef24336f |(disk.py:136) | Unable to get disk metrics for /sys/kernel/debug/tracing: [Errno 13] Permission denied: '/sys/kernel/debug/tracing'. You can exclude this mountpoint in the settings if it is invalid.
From what I've seen on threads, they gave this answer:
Can you add "tracefs" to the "file_system_blacklist" configuration to see if that unblocks you? We can add it by default if it does.
But I do not completely understand this answer, and I am not sure what should I change to fix this issue.
If anyone experiences this kind of thing and can help me it would be super helpful
Thank you!
With Datadog Agent 7:
mv /etc/datadog-agent/conf.d/disk.d/conf.yaml.default /etc/datadog-agent/conf.d/disk.d/conf.yaml
Then in /etc/datadog-agent/conf.d/disk.d/conf.yaml, uncomment file_system_global_exclude and underneath it add - tracefs:
init_config:
file_system_global_exclude:
- tracefs

Unable to mount /dev/pmem0 with 'dax' option

I am upgrading the kernel version from 4.14 to 5.4.103.
We have /dev/pmem0 created with the following command line: memmap=0x1000000!0x10000000
As a result /dev/pmem0 has been created. But, the mount command is failing with errors.
mount -o dax /dev/pmem0 /mnt/data1
[ 28.920384] squashfs: Unknown parameter 'dax'
[ 28.945516] EXT4-fs (pmem0): DAX unsupported by block device.
[ 28.951523] squashfs: Unknown parameter 'dax'
mount: mounting /dev/pmem0 on /mnt/data1 failed: Invalid argument
Can someone tell me whether something got changed with 5.4.x kernel version?
PS: If I remove the 'dax' option, mount becomes successful.

How is `KUBERNETES_PORT_443_TCP_ADDR` being set? Any pointers to Kubernetes source code?

When I run an image in Kubernetes with kubectl run, environment variables are injected into the container.
My problem is that the values are wrong. I do not have anything running at 10.0.0.1. I believe the correct value there would be 10.1.0.1. This misconfiguration causes, as far as I know, among other things, the error from kube-dns reproduced below.
I would like to ask how are these variables injected into the container, preferably for a link into the code which takes care of this (I could not find anything). Also, some hints where the value 10.0.0.1 could be coming from.
pod variables:
$ kubectl run -i --image=busybox --restart=Never -t busybox
If you don't see a command prompt, try pressing enter.
/ # env
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.0.0.1:443
HOSTNAME=busybox
SHLVL=1
HOME=/root
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443
KUBERNETES_SERVICE_HOST=10.0.0.1
PWD=/
kube-dns error:
$ kubectl --namespace kube-system logs kube-dns-2190035132-gxf80 kubedns
[...]
E0119 10:04:05.271499 55 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: Get https://10.0.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.0.0.1:443: i/o timeout
I0119 10:04:05.771477 55 dns.go:174] Waiting for services and endpoints to be initialized from apiserver...
The closest thing to 10.0.0.1 that I have in my config is --service-cluster-ip-range=10.0.0.0/24 parameter I am giving to kube-apiserver.
I have the IP 10.0.0.1 in my etcd, in
# ETCDCTL_API=3 etcdctl get "" --from-key
[...]
/registry/services/specs/default/kubernetes
k8s
v1Service
kubernetes▒default"*$b198bc22-fcff-11e7-83a9-185e0fec8ce528B
Z
component apiserverZ
provider
kuberneteszC
▒
httpsTCP▒▒(10.0.0.1" ClusterIPClientIPBRZ`▒
▒"
/registry/services/specs/kube-system/kubernetes-dashboard
k8s
v1Service
kubernetes-dashboard▒
kube-system"*$b9f0daef-fcff-11e7-83a9-185e0fec8ce528B
ԾZ,
addonmanager.kubernetes.io/mode ReconcileZ
ppkubernetes-dashboardZ*
kubernetes.io/minikube-addons dashboardZ3
&kubernetes.io/minikube-addons-endpoint dashboardb
0kubectl.kubernetes.io/last-applied-configuration{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","app":"kubernetes-dashboard","kubernetes.io/minikube-addons":"dashboard","kubernetes.io/minikube-addons-endpoint":"dashboard"},"name":"kubernetes-dashboard","namespace":"kube-system"},"spec":{"ports":[{"nodePort":30000,"port":80,"targetPort":9090}],"selector":{"app":"kubernetes-dashboard"},"type":"NodePort"}}
z_
TCP▒PG▒(
ppkubernetes-dashboard▒ 10.0.0.82NodePort:NoneBRZCluster`▒
▒"
https://github.com/kubernetes/kubernetes/blob/v1.9.0/pkg/kubelet/envvars/envvars.go#L45-L48 which I found via git grep SERVICE_PORT
It's possible that if your kubernetes.default.svc.cluster.local is pointing to the wrong IP, then kubectl --namespace=kube-system edit svc kubernetes and changing the ClusterIP would sort that out; I don't have a cluster in front of me to test it, though

dnsmasq: failed to create IPset control socket: Permission denied

When I start dnsmasq service in CentOS 7, I get such status:
This is because I add a wblist.conf in /etc/dnsmasq.d/wblist.conf
cat wblist.conf
# for router itself
server=/google.com.tw/192.168.8.20#53
ipset=/google.com.tw/gfwlist
ipset -L gfwlist
Name: gfwlist
Type: hash:net
Revision: 3
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 0
Members:
But if I COMMENT the ipset line, the service can be restarted successfully.
I don't know why. I have used dnsmasq/ipset for a long time, but suddenly got this problem.
Have anyone met this situation?
Disable SElinux is not recommend.
You can solve this problem by create and install a SELinux Policy Modules.
First you need create a type enforcement rules file called my-dnsmasq.te, content like below:
module my-dnsmasq 1.0;
require {
type dnsmasq_t;
class netlink_socket { bind create write };
}
#============= dnsmasq_t ==============
allow dnsmasq_t self:netlink_socket { bind create write };
Now you can compile it into a policy module package file:
checkmodule -M -m -o my-dnsmasq.mod my-dnsmasq.te
semodule_package -o my-dnsmasq.pp -m my-dnsmasq.mod
Once you get the policy module package file my-dnsmasq.pp, install it:
sudo semodule -i my-dnsmasq.pp
Finally, restart the dnsmasq.service:
sudo systemctl restart dnsmasq
And make a test like below:
nslookup google.com.tw
ipset list gfwlist
If everything is fine, you will see a ip is added to ipset.
I found this article SELinux prevents ipset from creating a netlink socket, and I disabled SELinux, then it worked. I don't know why.

Warning: Failed to connect to the agentx master agent ([NIL])

I have installed net-snmp5.7.2 on my system, I have written my app_agent.conf for my application and
agentXSocket udp:X.X.X.X:1610
and exported SNMPCONFIGPATH=path_to_app_agent.conf
I have also wrtten snmpd.conf in /usr/etc/snmp/snmp.conf
trap2sink X.X.X.Y
agentXSocket udp:X.X.X.X:1610
I have two more snmpd.conf present in my /etc/snmp/ and /var/net-snmp/
Config from /etc/snmp:
com2sec notConfigUser default public
com2sec notConfigUser v1 notConfigUser
com2sec notConfigUser v1 notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "" any noauth exact systemview none none
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat
Config from /var/net-snmp:
setserialno 1322276014
ifXTable .1 14:0 18:0x $
ifXTable .2 14:0 18:0x $
ifXTable .3 14:0 18:0x $
engineBoots 14
oldEngineID 0x80001f888000e17f6964b28450
I have started snmpd and snmptrapd. Now in my code I am calling
netsnmp_ds_set_boolean(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_ROLE, 1);
init_agent("app_agent");
init_snmp("app_agent");
init_snmp is throwing a warning
Warning: Failed to connect to the agentx master agent ([NIL]):
I have no idea why?? Thanks in advance for any help
This is basically saying the sub-agent you wrote failed to connect to NetSNMP master agent, as the message suggested. In Linux, by default agentx will attempt to make the connection via socket using /var/agentx/master. The following hint might help:
Running your sub-agent under appropriate privilege that has access
to sockets e.x. sudo
Check socket setting in your snmpd.conf (which located varies) if not already specified, such as
agentxsocket /var/agentx/master and agentxperms 777 777
Restart NetSNMP for any change to take effect with sudo service snmpd restart; or as an option you can try stop the service with sudo service snmpd stop and run an instance with debugging mode snmpd -f -Lo -Dagentx which most likely will output useful information on sub-agent connection.
I ran into this problem right now with quagga and ospfd and after doing an strace -f -p PID, noticed this among the output:
connect(14, {sa_family=AF_FILE, path="/var/agentx/master"}, 110) = -1 EACCES (Permission denied)
so I:
$ ls -al /var/agentx/
total 8
drwx------ 2 root root 4096 Sep 12 20:50 .
drwxr-xr-x. 27 root root 4096 Sep 12 20:13 ..
srwxrwxrwx 1 root root 0 Sep 12 20:50 master
and then I:
$ chmod 755 /var/agentx/
and immediately zebra and ospfd had their Agentx subnets connect.
$ tail -10f /var/log/quagga/zebra.log
2014/09/12 20:52:59 ZEBRA: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
$ tail -10f /var/log/quagga/ospfd.log
2014/09/12 20:52:59 OSPF: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
This is running quagga-0.99.23-2014062401 on RHEL6. hope this helps.
Had a similar problem, whether it be with the unix Sockets or Tcp:localhost:750 i was still getting the same error message:
/var/log/quagga/ospfd.log: warning, failed to connect to Master AgentX [nill] or [tcp:localhost:750].
I resolved the issue by disabling SELINUX.
This is not the answer to your problem, but I too got "Warning: Failed to connect to the agentx master agent ([NIL]):" message when my snmpd service didn't startup properly or went down. For my SNMP Sub-Agent, I used the example they provide, example-demon.c, and found I get this message nonstop (about every second) when processing agent_check_and_process(0) on every loop.
while (true) {
agent_check_and_process(0); /* 0 == don't block */
}
This is how I fixed it.
netsnmp_transport *snmpTransport;
while( true ) {
// Check to see snmpd is still running
snmpTransport = netsnmp_transport_open_client("agentx", NULL);
if (snmpTransport == NULL)
{
// Just went down?
if (snmpAgentDown == false)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is down\n" );
snmpAgentDown = true;
}
Sleep(5000); // Sleep for a 5 sec
} else
{
if (snmpAgentDown)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is back up\n" );
snmpAgentDown = false;
}
// Close connection test
snmpTransport->f_close(snmpTransport); // This burn me without; its needed
netsnmp_transport_free(snmpTransport);
// Process SNMP request and notifications
agent_check_and_process( 0 ); // 0 == don't block, 1 = block
Sleep(1); // Sleep for 1ms; Need to sleep thread, but need subAgent to be responsive too
}
i++;
}
Now if the snmpd goes down, my app can detect it being down and not process agent_check_and_process() stopping the "Warning: Failed to connect to the agentx master agent ([NIL]):" from ever appearing. If snmpd comes back up, then it processes it.
Final Note: I determine that code based off subagent.c file subagent_open_master_session() funtion in net-snmp-5.7.2 package. snmpTransport->f_close(snmpTransport) is also needed and determine that by following what snmp_close() did at the end of subagent_open_master_session() function.
As the subagent of Net-SNMP sometimes unable to read the adress of master agent from the configuration file, so you can even try
/* set the location of master agent */
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID,
NETSNMP_DS_AGENT_X_SOCKET, "udp:X.X.X.X:1610");
Write these lines in the agentx code before calling init_agent().
I have solved problem next comands line in OS Ubuntu 17.07
Change code (add line)
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.2
view systemview included .1.3.6.1.2.1.25.1.1
instead of
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
Write down new line master agentx in /etc/snmpd.conf
Restart snmpd demon:
sudo /etc/init.d/snmpd restart or sudo service snmpd restart

Resources