| What is the simplest data source for a cloud-init home lab? Posted: 29 Apr 2022 11:52 AM PDT I'm using cloud-init to spin up VMs using Ubuntu cloud images and kvm/qemu on a home server. I think I'm at the stage where I need to implement a data source because my VM creation dies if I try to write arbitrary files as a part of my init. Here's what I do to generate an ISO image containing the configuration data. cloud-localds --network-config=/srv/init/network-init.cfg /var/kvm/mldc-seed.qcow2 /srv/init/cloud-init.cfg
Here's an example of me trying to write a .tmux.conf file. If I leave this syntax in the ubuntu-cloud-init.cfg file, my VM creation fails and I'm not sure what log to tail for this. write_files: - path: /home/msh/.tmux.conf content: | unbind C-b set -g prefix C-a bind-key C-a last-window bind-key k confirm kill-window owner: 'muh:adm' permissions: '0640'
|
| In NVMe, what is the difference between a reserved log and an unsupported log? Posted: 29 Apr 2022 11:28 AM PDT I'm reading through the NVMe specification. On page 237 it says the following for get-log return value 0x09: Invalid Log Page: The log page indicated is invalid or not supported. This error condition is also returned if a reserved log page is requested. Controllers compliant with NVM Express Base Specification revision 1.3 and earlier may return Invalid Field in Command for this condition. What I'm not clear on is what is a reserved log page? I understand reserve values in the rest of the spec but this log page has been defined so it's not as if it is reserved for future use. There is a distinction made here between reserved and not supported. Does reserved mean you need a vendor key or something to look at it? |
| Security Headers X-XSS-Protection issue Posted: 29 Apr 2022 11:18 AM PDT Is there any issues coming from adding 'Strict-Transport-Security' and 'X-XSS-Protection' headers ? Header set Strict-Transport-Security "max-age=10886400; Header set X-XSS-Protection "1; mode=block"
I didn't put 'include Subdomains' for the HSTS header because I wasn't sure if we always want those over HTTPS. Specifically I could see this causing issues with HubSpot and/or CDN pages (slowing down the CDN delivery, not resolution issues). modern browsers may not even implement XSS filtering right ? if I'm not wrong Modern browsers prefer this right ? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy Our WAF will block XSS injections as well so the header wouldn't actually come into effect. Is CSP policy implementation will help ? what is the best advise here ? |
| Unable to use NetGear R6300v3 as a VPN Server behing a Google Wifi router Posted: 29 Apr 2022 11:17 AM PDT My Netgear R6700v3 has VPN server capabilities and i used it when i traveled outside the US to have a secure connection to my work systems from home IP. Now that I got a new ISP (Google WiFi) i thought i just need to connect my netgear to the Google Wifi router(wired), turn on port forwarding for the VPN server on the Netgear router and everything should just work, except that it does not. I am not able to connect to the router, even on the web interface when I am on the Google Wifi network. I see the device on the list of connected devices and I can ping it, but i can not access the web interface on that IP. I enable a ddns domain to access it remotely, but that has never worked. Any help would be appreciated. The network looks like this: [Internet] => [Google Router] => [NetGear (Vpn Server)] Google router ip 192.168.86.1 Netgear router ip 192.168.86.25 I am starting to think this is not possible via a google router, but though worth asking the community first. |
| Cloudflare not resolving adobe.com? Posted: 29 Apr 2022 11:04 AM PDT in my setup, a local Bind9 server forwards DNS requests to Cloudflare (1.1.1.1) with DNSSEC activated. My syslog shows many timeout entries for well known domain names (like adobe.com): Apr 28 19:39:01 myserver named[756]: timed out resolving 'adobeid-na1.services.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:03 myserver named[756]: timed out resolving 'adobelogin.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:04 myserver named[756]: timed out resolving 'www.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:04 myserver named[756]: timed out resolving 'ims-na1.adobelogin.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:04 myserver named[756]: timed out resolving 'sstats.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:04 myserver named[756]: timed out resolving 'auth.services.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:04 myserver named[756]: timed out resolving 'geo2.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:39:05 myserver named[756]: timed out resolving 'images-tv.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:42:46 myserver named[756]: timed out resolving 'adobeid-na1.services.adobe.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:42:46 myserver named[756]: timed out resolving 'ims-na1.adobelogin.com/HTTPS/IN': 1.1.1.1#53 Apr 28 19:42:46 myserver named[756]: timed out resolving 'auth.services.adobe.com/HTTPS/IN': 1.1.1.1#53
but the domain names are resolved properly with nslookup. What is happening here? Thanks, Jan |
| View all records in Algolia dashboard Posted: 29 Apr 2022 11:01 AM PDT We have an Algolia project that has 2929 records. In the search field on the web dashboard, it only allows us to page through 235 records. Is there any way to page through all records in the dashboard? Or is there another way to see all records in table form in the dashboard? |
| DS requests sent to Cloudflare for internal TLD Posted: 29 Apr 2022 10:53 AM PDT I created a Bind9 configuration to provide DNS entries for an internal TLD. Bind9 uses Cloudflare as forwarder: options { directory "/var/cache/bind"; dnssec-validation auto; validate-except { "mytld"; }; forwarders { 1.1.1.1; }; listen-on { 127.0.0.1; 192.168.78.0/24; }; }
and (almost) everything works as expected. But every request for my TLD causes DS requests to Cloudflare: 16:28:34.165569 IP myserver.49728 > one.one.one.one.domain: 45669+% [1au] DS? mytld. (46) 16:28:34.179688 IP one.one.one.one.domain > myserver.49728: 45669 NXDomain* 0/6/1 (1026)
validate-except obviously does not keep the local Bind9 from forwarding a DS request – is there another way to keep DNS traffic for .mytld entirely local?
Thanks, Jan |
| Yum install/update hangs at the very end, unable to kill via ctrl-c Posted: 29 Apr 2022 10:37 AM PDT So I've got a group of servers (all RHEL 7.9) whose RPMDBs appear to have become corrupted. Not sure how or when, but no matter. I fixed the DBs using these instructions. After that, any attempt to install/update/remove software using yum causes it to hang at the very end. I get the final line "Loaded plugins: product-id, subscription-manager", and then it just sits. Ctrl-C won't break out of it, I have to either close my SSH session or wait for it to timeout, and then I can kill hung yum processes and delete lock files. Once I run yum-complete-transaction to clear anything left over, yum will allow me to do whatever, but it still hangs the same way at the end of any install/remove/update. What I have done: - Checked for any hung/dormant NFS mounts
- Rebuilt the DB again just in case something weird happened the first time through
- Ran yum clean all
- Tried installing/updating/removing via plain RPM, and that works, but has no impact on the problem with yum
- Found a stack overflow page that suggested IPV6 was causing issues, so I disabled that by setting net.ipv6.conf.[nic].disable_ipv6 = 1
No impact from any of this. Anyone have any thoughts? |
| Admin user not show under base dc after setup openldap on debian Posted: 29 Apr 2022 09:33 AM PDT After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1), I could not found the admin user (cn=admin,dc=company,dc=com) in the phpldapadmin dashboard. I also tried using Apache Directory Studio to access the LDAP directory, still couldn't find the admin user. screenshot of empty entry under my dc However, using ldapwhoami (ldapwhoami -vvv -h ldap.company.com -D cn=admin,dc=company,dc=com -x -w password) can return a succesful result, using the admin user can also be able to log in into the phpldapadmin dashboard (which may indicates that the admin user is successfully created?). So how could I configure the openldap or phpldapadmin to find the admin user in order to edit its attributes? A similar issue can be found here: https://github.com/osixia/docker-openldap/issues/555 |
| What are the "alternatives" to Heketi for Kubernetes? Posted: 29 Apr 2022 09:23 AM PDT I have built a working GlusterFS cluster, and now I want to make a Kubernetes StorageClass that uses it. I see a number of tutorials and documentation pointing to Heketi as the provisioner engine. Looking at that page, however, it has the following admonition: It has been well over a year since we first entered maintenance mode. To anyone looking at creating a new install using Heketi: we highly encourage you to look at other appraoches to dynamic storage provisioning, especially if you're not already very familiar with Heketi/Gluster. This doesn't seem like something I want to invest a lot of time in learning or deploying. So what are the "other approaches" that are being referred to? Can anyone provide some pointers? Web searches don't seem to come up with anything. |
| Dovecot claims ports are in use, netstat disagrees Posted: 29 Apr 2022 10:30 AM PDT Attempting to start dovecot gives me this: Apr 28 13:37:00 master: Error: service(pop3-login): listen(*, 110) failed: Address already in use Apr 28 13:37:00 master: Error: service(pop3-login): listen(*, 995) failed: Address already in use Apr 28 13:37:00 master: Error: service(imap-login): listen(*, 143) failed: Address already in use Apr 28 13:37:00 master: Error: service(imap-login): listen(*, 993) failed: Address already in use
And 'netstat -tulpn' displays this: tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 3369/master tcp 0 0 0.0.0.0:52125 0.0.0.0:* LISTEN 2396/rpc.statd tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3244/mysqld tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2375/rpcbind tcp 0 0 :::22 :::* LISTEN 2562/sshd tcp 0 0 :::25 :::* LISTEN 3369/master tcp 0 0 :::443 :::* LISTEN 3390/httpd tcp 0 0 :::39631 :::* LISTEN 2396/rpc.statd tcp 0 0 :::111 :::* LISTEN 2375/rpcbind tcp 0 0 :::80 :::* LISTEN 3390/httpd udp 0 0 0.0.0.0:68 0.0.0.0:* 2236/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 2375/rpcbind udp 0 0 10.0.82.190:123 0.0.0.0:* 2589/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 2589/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 2589/ntpd udp 0 0 0.0.0.0:43243 0.0.0.0:* 2396/rpc.statd udp 0 0 0.0.0.0:854 0.0.0.0:* 2375/rpcbind udp 0 0 127.0.0.1:876 0.0.0.0:* 2396/rpc.statd udp 0 0 :::111 :::* 2375/rpcbind udp 0 0 :::854 :::* 2375/rpcbind udp 0 0 :::54504 :::* 2396/rpc.statd
Any idea what I'm missing here? UPDATE: selinux is disabled, and the distro is AWX Linux: $ getenforce Disabled $ uname -a Linux ip-10-0-82-190 4.14.268-139.500.amzn1.x86_64 #1 SMP Wed Mar 2 18:48:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
|
| Restart rspamd.service as non-root user Posted: 29 Apr 2022 09:21 AM PDT I have webpage with button, when user clicks on button, script restart.sh on server is executed. This script contains: #!/bin/bash systemctl restart rspamd.service
After clicking on the button, restart.sh is executed, but rspamd.service is not restarted: "Failed to restart rspamd.service: Access denied" Because the script is executed by click on button on webpage, the real user who runs it on server is www-data. I tried to set suid bit to run script as root, but it's not working. How can I restart rspamd.service as www-data user? |
| Docker container has no internet ... GoDaddy hosting Posted: 29 Apr 2022 11:01 AM PDT It's GoDaddy hosting (Linux 4.15.0-176-generic #185-Ubuntu)
docker 1.5-1build1
$ docker pull busybox $ docker run busybox ping -c 5 google.com PING google.com (142.251.33.206): 56 data bytes --- google.com ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
$ docker run busybox wget -t 1 -T 1 google.com Connecting to google.com (142.251.33.206:80) wget: download timed out
It's works when host network is used $ docker run --net host busybox wget -t 1 -T 1 google.com Connecting to google.com (172.217.9.206:80) Connecting to www.google.com (172.217.0.36:80) saving to 'index.html' index.html 100% |********************************| 14585 0:00:00 ETA 'index.html' saved
Routing issue maybe $ docker run busybox traceroute -m 15 google.com traceroute to google.com (142.250.81.206), 15 hops max, 46 byte packets 1 172.17.0.1 (172.17.0.1) 0.012 ms 0.010 ms 0.010 ms 2 10.198.71.252 (10.198.71.252) 0.338 ms 0.215 ms 0.258 ms 3 10.243.128.110 (10.243.128.110) 0.299 ms 10.243.128.108 (10.243.128.108) 0.265 ms 0.230 ms 4 10.243.128.58 (10.243.128.58) 0.310 ms 10.243.128.62 (10.243.128.62) 0.209 ms 10.243.128.58 (10.243.128.58) 0.218 ms 5 10.207.252.24 (10.207.252.24) 0.252 ms 10.207.252.14 (10.207.252.14) 0.321 ms 0.235 ms 6 10.242.134.76 (10.242.134.76) 0.236 ms 0.181 ms 10.242.134.68 (10.242.134.68) 0.225 ms 7 148.72.36.58 (148.72.36.58) 3.341 ms 0.492 ms 10.240.88.24 (10.240.88.24) 7.847 ms 8 148.72.36.46 (148.72.36.46) 0.707 ms 0.568 ms 148.72.36.50 (148.72.36.50) 10.467 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * *
|
| Can I stop a SPF SOFTFAIL in Gmail when sending to and from addresses that have a mail alias? Posted: 29 Apr 2022 10:20 AM PDT I have a vanity domain (mydomain.com) hosted by Gandi and configured with mail aliases for my family that point to our respective Gmail addresses: | Alias | Real address | | me@mydomain.com | me5678@gmail.com | | mybrother@mydomain.com | brother1234@gmail.com | and so on. Gmail is configured to send email as the vanity address and I also have a SPF record set up: v=spf1 include:_spf.google.com include:_spf.gpaas.net include:_mailcust.gandi.net ?all
Although mail-tester.com reports that the SPF is set up correctly, it's possible to get a SOFTFAIL in the most common use-case (when sending an email from mydomain.com to someone else at mydomain.com): | Sent from | Sent to | SPF result of email | | me5678@gmail.com | brother1234@gmail.com | PASS | | me5678@gmail.com | mybrother@mydomain.com | PASS | | me@mydomain.com | brother1234@gmail.com | PASS | | me@mydomain.com | mybrother@mydomain.com | SOFTFAIL | The SOFTFAIL details are: ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning brother1234@gmail.com does not designate 2001:4b98:dc4:8::222 as permitted sender) smtp.mailfrom=brother1234@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mydomain.com Return-Path: <brother1234@gmail.com> Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net. [2001:4b98:dc4:8::222]) by mx.google.com with ESMTPS id m12-20020adfdc4c000000b00207b0b06b7csi3909665wrj.123.2022.04.13.11.40.22 for <me5678@gmail.com> (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Apr 2022 11:40:22 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning brother1234@gmail.com does not designate 2001:4b98:dc4:8::222 as permitted sender) client-ip=2001:4b98:dc4:8::222; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning brother1234@gmail.com does not designate 2001:4b98:dc4:8::222 as permitted sender) smtp.mailfrom=brother1234@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mydomain.com
Is there any way I can stop emails sent from mydomain.com to another address at mydomain.com failing SPF? |
| How can I configure my nginx server to accept different subdomains and also port? Posted: 29 Apr 2022 09:37 AM PDT I have a server running on Ubuntu/Nginx. I have subdomains running from different internal ports. I want to expose one application to the public but not associate it with any domain/server name. Below is my configuration file: server { server_name app.example.com www.app.example.com; access_log /home/hub-app/logs/app.example.com.access.log; location / { proxy_set_header Host $host; proxy_pass http://127.0.0.1:8082; proxy_redirect off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_cache_bypass $http_upgrade; proxy_http_version 1.1; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; } server { server_name example.com www.example.com; access_log /home/hub-public/logs/example.com.access.log; location / { proxy_set_header Host $host; proxy_pass http://127.0.0.1:8081; proxy_redirect off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_cache_bypass $http_upgrade; proxy_http_version 1.1; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; }
The above works well and points to the specified domains ie example.com and app.example.com. Now I want to add another virtual server to run at MY_PUBLIC_IP:8080. The port 8080 should not be accessible on the other domains i.e. example.com:8080/app.example.com:8080 should not be available. |
| Configure nginx to serve query string parameter Posted: 29 Apr 2022 09:25 AM PDT We have one NextJs site, with next export we get one out folder which we want to serve from Nginx. In out/login there is one '[[...parameter]].html'. When we deploy site using pm2 it is working if we hit url "serverIP:port/login/programID/applicant" But when serving through nginx it is not working. Below is the nginx configuration file content: server{ listen 7001; server_name server_ip; root /var/www/html/out/; location / { try_files $uri $uri.html $uri.html/ =404; }
} Please help. I am new to nginx so having some difficulties. |
| What is this possible Apache exploit, and am I affected? Posted: 29 Apr 2022 10:25 AM PDT I had this warning in my daily logwatch digest this morning: A total of 1 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that indicate a possible exploit): /?unix:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|http://xxxxxxxxxxxxxxxxxx.oast.live/ HTTP Response 200
(real URL obscured for obvious reasons - will post it if it's important to someone) Google returns nothing about an exploit like this, but possibly because the string of repeated As is being truncated or something (although I have used quotes etc). What exploit is logwatch warning about, and how I can be sure if I was impacted or not? This is the entry from the Apache access.log: access.log.1:176.113.115.238 - - [24/Apr/2022:17:15:03 +0100] "GET /?unix:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|http://xxxxxxxxxxxxxxxxx.oast.live/ HTTP/1.1" 200 6142 "-" "Mozilla/5.0 (Windows NT 4.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36"
|
| winbind Could not connect to dssetup pipe: NT_STATUS_RPC_INTERFACE_NOT_FOUND Posted: 29 Apr 2022 11:18 AM PDT I am trying to add a new member server running Ubuntu to a Samba Active Directory domain. On first glance everything seems to work, but when querying the status of the winbind service with service winbind status, I'm getting the following messages (most of it in red, so it's probably an error even though there are several messages in green saying "ready"): ● winbind.service - Samba Winbind Daemon Loaded: loaded (/lib/systemd/system/winbind.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-04-21 15:47:43 UTC; 17h ago Docs: man:winbindd(8) man:samba(7) man:smb.conf(5) Main PID: 1728 (winbindd) Status: "winbindd: ready to serve connections..." Tasks: 5 (limit: 76899) Memory: 27.0M CGroup: /system.slice/winbind.service ├─1728 /usr/sbin/winbindd --foreground --no-process-group ├─1738 winbindd: domain child [MYSERVER] ├─1739 winbindd: domain child [MYDOMAIN_AD] ├─1754 winbindd: idmap child └─5023 winbindd: domain child [BUILTIN] Apr 21 15:47:43 myserver.ad.mydomain.com systemd[1]: Starting Samba Winbind Daemon... Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1728]: [2022/04/21 15:47:43.857695, 0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache) Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1728]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1728]: [2022/04/21 15:47:43.861490, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1728]: daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections Apr 21 15:47:43 myserver.ad.mydomain.com systemd[1]: Started Samba Winbind Daemon. Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1738]: [2022/04/21 15:47:43.864574, 0] ../../source3/winbindd/winbindd_cm.c:1873(wb_open_internal_pipe) Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1738]: open_internal_pipe: Could not connect to dssetup pipe: NT_STATUS_RPC_INTERFACE_NOT_FOUND Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1738]: [2022/04/21 15:47:43.867483, 0] ../../source3/rpc_server/rpc_ncacn_np.c:454(rpcint_dispatch) Apr 21 15:47:43 myserver.ad.mydomain.com winbindd[1738]: rpcint_dispatch: DCE/RPC fault in call lsarpc:2E - DCERPC_NCA_S_OP_RNG_ERROR
uname --all output:
Linux myserver 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
winbindd --version output:
Version 4.13.17-Ubuntu
The AD Primary and Secondary domain controllers are up and running. All computers are running Unbuntu Linux 20.04 and all packages are up to date. There is no Windows server involved or even in the network. I have no idea what causes this and how I can fix it. Google didn't turn up anything useful either. Any hints? Are there any other logs where I could look for more information? |
| When trying to nfs4 mount a share with sec=krb5 I get "not exported" error message on nfs server Posted: 29 Apr 2022 09:54 AM PDT I run two nfs servers with user home directories and other shares on them. The servers offer kerberized nfsv4 mounts as well as old v3 ones. Until recently I was able to nfs4-mount a krb5-exported share from one server on the second without any problems. If I try now I get an permission denied and in the nfs server log I always see this error shown below. The filesystems with userdata on the nfs servers are located in /export/user1 on host server1.uni-ko.de and /export/user2 on host server2.uni-ko.de (hostnames changed). The path /export/ is used as common nfs4 export root marked by fsid=0. ## run on host server1.uni-ko.de # mount -t nfs4 -o sec=krb5 server2.uni-ko.de:/user2 /mnt mount.nfs4: access denied by server while mounting server2.uni-ko.de:/user2
and in the nfs servers log I see this error: refused mount request from server1.uni-ko.de for /user2 (/): not exported
The same happens if I try to locally mount a share on the same host via nfs4 like this: ## on host server1.uni-ko.de # mount -t nfs4 -o sec=krb5 server1.uni-ko.de:/user1 /mnt mount.nfs4: access denied by server while mounting server1.uni-ko.de:/user1
A nfs3 mount (mount server1.uni-ko.de:/export/user1 /mnt) is possible without any problems. The /etc/exports file on host server2.uni-ko.de looks like this: /export gss/krb5(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \ gss/krb5i(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \ gss/krb5p(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) # NFS V3 exports via NIS netgroups /export/user2 @nfsv3client(rw,async,no_subtree_check,no_subtree_check,fsid=2000)
exportfs -v shows the shares are (krb5-nfs4) exported: # exportfs -v .... /export gss/krb5(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash) /export gss/krb5i(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash) /export gss/krb5p(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash) /export/user2 @nfsv3client(rw,async,wdelay,hide,no_subtree_check,fsid=2000,sec=sys,secure,root_squash,no_all_squash)
Things get even more strange since from a default nfs4 client I am still able to nfs4 mount the given directory without any problems exactly as described above and both systems share the same OS in der very same version and patch level which is SuSE SLES15SP3 with the latest patches installed. On the nfs servers there is a firewall running opening the statically assigned ports needed for NFS like mountd,statd,lockd as well as ports 111 and 2049 (all opened for tcp and udp). This is what I changed recently. Before this change nfs server ports were not static but set by defaults, but I cannot see how this could lead to the strange mount behavior described. I also disabled the firewall completely and tested again with the same result. Behind the scenes there is a kerberos server running keeping all the principals needed. For the nfs servers and all nfs4 clients there are "nfs" and "host" principals available and each server and client has a /etc/krb5.keytab containing the exported "nfs" and "host" principal for this host. Of course user principals are also stored in the kerberos server. This all worked flawlessly for years and still does, except for the described problem which is new. |
| Failed to map guest I/O buffer for write access with status 0xC0000044 Hyper-V-StorageVSP Event ID 8 Posted: 29 Apr 2022 10:43 AM PDT Full Error information: Error 8/9/2021 10:35:11 AM Hyper-V-StorageVSP 8 None Failed to map guest I/O buffer for write access with status 0xC0000044. Device name = d:\vms\servername\virtual hard disks\servername.vhdx This error is switching between different vhdx files on the same Cluster Shared Volume. Some days it reports on servername1.vhdx others on servername2.vhdx  I recently updated all firmware and drivers on this server HP DL360 Gen 10, Broadcom NX1 i311 network adapters. No change still reports these errors from time to time for a day or so. Also running Shadow Protect as backups service. I'm not experiencing negative impact from these events and it looks like others have run into them as well without resolution from MS support: https://docs.microsoft.com/en-us/answers/questions/267595/windows-10-vms-generating-storage-errors-on-2019-h.html I'll update as I learn more. |
| Infiniband drivers : OFED or distro included? Posted: 29 Apr 2022 10:41 AM PDT I'm setting up a Linux cluster with infiniband network, and I'm quite a newby in infiniband wolrd, any advice is more than welcome ! We are currently using Mellanox OFED drivers, but our infiniband cards are old and not recognized by the latest MOFED drivers. So I'm wondering why not to use distribution shipped drivers (running CentOS7). What difference will that make to use one or another ? Should I expect any performance decrease ? thx |
| virt-install: error: unrecognized arguments: (but no arguments listed) Posted: 29 Apr 2022 12:01 PM PDT Been trying to create my first VM with KVM but getting a cryptic error from virt-install. It's saying I have a 'unrecognized arguments' but does not say which argument: $ sudo virt-install \ > --name centos7_vm1 \ > --memory 1024 \ > --disk /data/kvm_images/centos7-vm1.qcow2,device=disk \ > --disk /data/kvm_images/centos7-vm1.iso,device=cdrom \ > --os-type linux \ > --os-variant centos7.0 \ > --virt-type kvm \ > --graphics none \ > --network default \ > --import usage: virt-install --name NAME --memory MB STORAGE INSTALL [options] virt-install: error: unrecognized arguments: $
Looking at docs and general googling cant work out what is wrong. Ime running CentOS 7, virt-install 1.5.0. $ ls -l /data/kvm_images total 70584 -rw------- 1 qemu qemu 26847870976 May 11 00:06 centos7-docker.qcow2 -rw-r--r-- 1 root root 374784 May 11 14:35 centos7-vm1.iso -rw-r--r-- 1 root root 68026368 May 11 14:02 centos7-vm1.qcow2 -rw-r--r-- 1 root root 104 May 11 14:33 centos7-vm1.setup.yaml $
Here are what I did to get this far The first thing I did was download the image $ wget wget https://cloud.centos.org/centos/7/images/CentOS-7-ppc64le-GenericCloud-2003.qcow2
Then checked it seemed OK $ qemu-img info CentOS-7-ppc64le-GenericCloud-2003.qcow2 image: CentOS-7-ppc64le-GenericCloud-2003.qcow2c file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 395M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false
Then I resized it to twenty-five GB $ qemu-img resize CentOS-7-ppc64le-GenericCloud-2003.qcow2 25G
And used qemu-img convert $ sudo qemu-img convert -f qcow2 -O qcow2 CentOS-7-ppc64le-GenericCloud-2003.qcow2 /data/kvm_images/centos7-vm1.qcow2
I then created a file centos7-vm1.setup.yaml #cloud-config password: xxxxxxxxxx chpasswd: { expire: False } ssh_pwauth: True hostname: centos7-vm1
and run $ sudo cloud-localds centos7-vm1.iso centos7-vm1.setup.yaml |
| Podman rootless journald logging Posted: 29 Apr 2022 10:01 AM PDT I'm trying to log to the host's systemd-journald from a rootless podman-container. When i run the container as root with the --privileged flag, i can read the logs from the container on the host with journalctl as expected. However, running the container in rootless mode breaks said logging-functionality (nothing shows up in jornalctl). Is there any way to solve this? |
| Change error page for 502 Bad Gateway error Nginx not working Posted: 29 Apr 2022 11:06 AM PDT I have researched online for a means to change the error page when running into a 502 Bad Gateway error. I have tried all the methods given to no avail. I looked in the nginx.conf file and saw that it points to /usr/share/nginx/html/50x.html when dealing with 500 errors. However this page is never shown. Instead it shows 502 Bad Gateway
nginx/1.16.1 What am I missing? I followed this guide https://blog.adriaan.io/one-nginx-error-page-to-rule-them-all.html And others, but I am beginning to think that there is another issue altogether that is bypassing my code. |
| How to make sssd obtain a ticket to mount NFS shares for the service? Posted: 29 Apr 2022 11:04 AM PDT I have a working setup in a corporate environment where we use RHEL7 together with SSSD to authenticate against Active Directory. Regular authentication works well. I managed to get the NFSv4 server to work with NFSv4 clients all using the same domain together with Kerberos and SSSD but only in an interactive fashion (ie: SSSD auto-create ticket at login time or manually using kinit). The purpose of these NFS shares is to store some content that will need to be accessible from applicative users (ie httpd or tomcat). What is the best approach for such deployment to make the access possible to the user in a non-interactive way? |
| openLDAP ldap_modify: Server is unwilling to perform (53) when trying to delete custom schema Posted: 29 Apr 2022 08:59 AM PDT I have created this custom and very basic schema: objectclass ( 2.25.2.2.1 NAME 'myObjectClass' DESC 'myObjectClass objectclass' STRUCTURAL MUST ( cn ) )
I have added it without problem with this myObjectClass.ldif file: dn: cn=myObjectClass,cn=schema,cn=config objectClass: olcSchemaConfig cn: myObjectClass olcObjectClasses: {0}( 2.25.2.2.1 NAME 'myObjectClass' DESC 'myObjectClass objectclass' STRUCTURAL MUST cn )
Using ldapmodify: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f myObjectClass.ldif
Now I'm trying to delete it with delete.ldif: dn: cn=schema,cn=config changetype: modify delete: objectClass objectClass: 2.25.2.2.1
Using ldapmodify always get ldap_modify: Server is unwilling to perform (53): sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f delete.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=schema,cn=config" ldap_modify: Server is unwilling to perform (53)
I'm running Ubuntu 14.04 Server with OpenLDAP 2.4.31 I have searched this in the official docs: A.2.2. Better cn=schema functionality In 2.3 you were only able to add new schema elements, not delete or modify existing elements. In 2.4 you can modify schema at will. (Except for the hardcoded system schema, of course.) Can someone share any clue? Thanks in advance! |
| Imapsync authentication login error Posted: 29 Apr 2022 10:01 AM PDT I have deployed my own domain over cPanel server and have used imapsync to backup my google app email to my local domain email. But i'm facing below error. I've switched on "Access for less secure apps" and enabled imap from gmail settings: /usr/bin/imapsync --host1 imap.gmail.com --user1 EMAILID1 --ssl1 --port1 993 --password1 MASKED --syncinternaldates --host2 mail.mydomainname --user2 EMAILID2 --password2 MASKED
Command line Output: Temp directory is /tmp ( to change it use --tmpdir dirpath ) PID file is /tmp/imapsync.pid ( to change it use --pidfile filepath ; to avoid it use --pidfile "" ) Wrinting my PID 31248 in /tmp/imapsync.pid Modules version list: Mail::IMAPClient 3.38 IO::Socket 1.38 IO::Socket::INET 1.35 IO::Socket::INET6 2.72 IO::Socket::SSL 2.024 Net::SSLeay 1.72 Compress::Zlib 2.068 Digest::MD5 2.54 Digest::HMAC_MD5 1.01 Digest::HMAC_SHA1 1.03 Term::ReadKey 2.33 File::Spec 3.56 Time::HiRes 1.9726 Unicode::String 2.10 IO::Tee 0.64 File::Copy::Recursive 0.38 Authen::NTLM 1.09 URI::Escape 3.31 Data::Uniqid 0.12 JSON 2.90 JSON::WebToken 0.10 Crypt::OpenSSL::RSA ? LWP 6.15 HTML::Entities 3.69 Getopt::Long 2.45 Test::MockObject 1.20161202 ( use --no-modulesversion to turn off printing this Perl modules list ) SSL debug mode level is --debugssl 1 (can be set from 0 meaning no debug to 4 meaning max debug) Host1: SSL default mode is like --sslargs1 SSL_verify_mode=0 meaning SSL_VERIFY_NONE on host1 (do not check the certificate server) Host1: Use --sslargs1 SSL_verify_mode=1 for SSL_VERIFY_PEER on host1 Info: turned ON syncinternaldates, will set the internal dates (arrival dates) on host2 same as host1. Host1: will try to use LOGIN authentication on host1 Host2: will try to use LOGIN authentication on host2 Host1: imap connexion timeout is 120 seconds Host2: imap connexion timeout is 120 seconds Host1: IMAP server [imap.gmail.com] port [993] user [EMAILID1] Host2: IMAP server [mail.mydomainname] port [143] user [EMAILID2] Host1: connecting and login on host1 [imap.gmail.com] port [993] with user [EMAILID1] Host1 banner: * OK Gimap ready for requests from MYWANIP j22mb61820836wrb Host1: imap.gmail.com says it has NO CAPABILITY for AUTHENTICATE LOGIN Host1 failure: Error login on [imap.gmail.com] with user [EMAILID1] auth [LOGIN]: * BYE System Error j22mb61820836wrb; * BYE System Error w191mb503225056wmw; * BYE System Error f194mb800234777wmg; * BYE System Error tt3mb112923762wjc; * BYE System Error 3mb869986783wrx
|
| Install ssconvert (part of gnumeric) on a server without GNOME Posted: 29 Apr 2022 09:14 AM PDT I need to use gnumeric's file conversion tool ssconvert on a server. The problem is that gnumeric is a gnome application and can't be installed without a desktop installed. There is also no separate packages for ssconvert, and I can not compile it from source code... I need this specific conversion tool cause it can covert from Excel XML format to CSV, which I was unable to do with other excel conversion tools. I am working on a ubuntu 12.04 server. I would appreciate any ideas. |
| ASE reports messages as spam? Posted: 29 Apr 2022 11:06 AM PDT Outside users are attempting to send to our domain (www.lrffpd.com). It's getting rejected sporatically. All of the senders are getting some variation of the error "Unagi.teksnax.com has rejected the message. This message has been blocked because ASE reports it as spam". The error number varies. - Our firewall is a Fortigate and it runs the built-in Fortigate AntiSpam software. I don't this problem is becuase of the firewall because the error is coming from the server, not the firewall.
- On the Exchange 2003 server we run ESET NOD32 for Exchange (only for AntiVirus). We also run the IMF filter built into Exchange.
I've NEVER heard of ASE and can't find any information about them. What do you think this could be? |
| Getting Access Denied While Accessing the Named Pipe from Another System Posted: 29 Apr 2022 12:01 PM PDT I have a Named Pipe and It Works Fine While I access it using a Client which runs on My System. I get GLE 5 (Access denied) while I run the client from another system. The original post is at stackoverflow |
No comments:
Post a Comment