manilx
April 29, 2021, 7:30am
1
Hi
I lately get this error, today while updating dietpi. It’s nothing serious but I’d like to remove it.
[FAILED] DietPi-Survey | Purging survey data
Any idea on how to fix this?
Thx in advance
Hi,
the system is trying to delete survey data you sent in past
curl -m 20 -sT 3709cbe9-41b6-436e-b393-d86a27a12a97.txt sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com/survey/
But it seems this data did not exist anymore.
MichaIng
can you verify this pls
manilx
April 29, 2021, 8:11am
3
Where should I look for this?
I disables survey but I still get this.
you are not able to verify this as survey data are located on DietPi web server. This can be done by the developer only.
manilx
April 29, 2021, 8:13am
5
Ah OK!!! Nothing I can do on my end then.
Yes because you disabled survey, the system is trying to purge old data sent in past. Give time to the developer to have a look.
That should upload an empty file and overwrite any existing data by this. If it fails, no data is purged, but probably none was there anyway.
But I had a look and that data is still on the server, last change on March 12.
Can you run the command manually from console and check the error message:
# Create an empty file
> 3709cbe9-41b6-436e-b393-d86a27a12a97.txt
# Upload it
curl -m 20 -T 3709cbe9-41b6-436e-b393-d86a27a12a97.txt sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com/survey/
But now, may I ask why you want to opt out?
This data is very valuable for us, as we can see
which DietPi versions users use, hence how long we must keep upgrade/migration code
which SBCs are used how often and which not at all (we just had such an case, zero users, hence only a waste of time to generate and maintain the related image)
which software titles we should prioritise or keep compatible when e.g. upstream changes or abandoned projects make it difficult
and of course the the benchmarks are interesting to compare own results against and get a rough idea about the performance of different SBCs.
All uploaded data is transparently seen in the script and public here as combined statistics: https://dietpi.com/survey/
We see a downwards trend in percentage of opted in users since the beginning, which decreases the value and statistical certainty of the data. E.g. even that we do not see any reported use of a specific SBC or software, with 86% of users not telling it, there might be still some. Especially the lower numbers might be very different. So I tried here and there do advertise dietpi-survey, but without any effect on the downwards trend. So I’m very interested in what exactly leads to the opt out decision and if we can e.g. change something about how, when or what is uploaded to act against it, e.g. raising users trust.
Best regards .
manilx
April 29, 2021, 12:09pm
8
Hi
Will do that once I get to the unit later today and report.
But I want to answer your question right away:
I have opted out after I received the error to try to fix it…
I have no problem opting in again. Actually I have all devices opted in (I’ll double check this also later )
manilx
April 29, 2021, 1:42pm
9
Got this:
root@piHole:~# # Create an empty file
root@piHole:~# > 3709cbe9-41b6-436e-b393-d86a27a12a97.txt
root@piHole:~# # Upload it
root@piHole:~# curl -m 20 -T 3709cbe9-41b6-436e-b393-d86a27a12a97.txt sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com/survey/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL peer certificate or SSH remote key was not OK
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
hmm I was using dietpi-survey to toggle between OPTED IN/OPTED OUT and it was working without issues.
root@DietPi3:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=1
[ OK ] DietPi-Survey | Sending survey data
root@DietPi3:~#
root@DietPi3:~#
root@DietPi3:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=0
[ OK ] DietPi-Survey | Purging survey data
root@DietPi3:~#
manilx
April 29, 2021, 9:43pm
11
hmm I was using dietpi-survey to goggle between OPTED IN/OPTED OUT and it was working without issues.
root@DietPi3:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=1
[ OK ] DietPi-Survey | Sending survey data
root@DietPi3:~#
root@DietPi3:~#
root@DietPi3:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=0
[ OK ] DietPi-Survey | Purging survey data
root@DietPi3:~#
root@piHole:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=0
[FAILED] DietPi-Survey | Purging survey data
- Command: curl -m 20 -sT 3709cbe9-41b6-436e-b393-d86a27a12a97.txt sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com/survey/
root@piHole:~# dietpi-survey
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=1
[FAILED] DietPi-Survey | Sending survey data
- Command: curl -m 20 -sT 3709cbe9-41b6-436e-b393-d86a27a12a97.txt sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com/survey/
can you check how the certificate look from your side
openssl s_client -showcerts -connect ssh.dietpi.com:443
It might be a long answer. Just try to copy whole output.
manilx
April 29, 2021, 10:00pm
13
root@piHole:~# openssl s_client -showcerts -connect ssh.dietpi.com:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dietpi.com
verify return:1
---
Certificate chain
0 s:CN = dietpi.com
i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
MIIErDCCA5SgAwIBAgISBENyYQe4cJno44PcuuzQwALlMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTAzMTMyMzI1NTBaFw0yMTA2MTEyMzI1NTBaMBUxEzARBgNVBAMT
CmRpZXRwaS5jb20wdjAQBgcqhkjOPQIBBgUrgQQAIgNiAARevH7iBpwoHIGwHTH7
rKJtyvjwADQxI20qcgVKnDVEwKuJMtcor+N9PMB/ei/kkgzT+lH8iTOwF81nbn7H
5MbBKjWbFEWPDErqTC+xlexoXHmkg49CO2AaPy8T5eoR7GCjggKFMIICgTAOBgNV
HQ8BAf8EBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1Ud
EwEB/wQCMAAwHQYDVR0OBBYEFNoGDBDy/CvYisa6ObHInV/oALhBMB8GA1UdIwQY
MBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEF
BQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8v
cjMuaS5sZW5jci5vcmcvMEMGA1UdEQQ8MDqCCmRpZXRwaS5jb22CC2Z1em9uLmNv
LnVrgg5zc2guZGlldHBpLmNvbYIPd3d3LmZ1em9uLmNvLnVrMBEGCCsGAQUFBwEY
BAUwAwIBBTBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYG
CCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB
1nkCBAIEgfQEgfEA7wB1APZclC/RdzAiFFQYCDCUVo7jTRMZM7/fDC8gC8xO8WTj
AAABeC4f+iYAAAQDAEYwRAIgKM8nSzfOaqABaO3a1ssdMmNQw4PYHtbOCv2Q/pbB
M+cCIDOVJk3LV8gWEE01iTvCPdHIwV8YLXe1Jd/aTGGaC6tYAHYAb1N2rDHwMRnY
mQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAF4Lh/8YQAABAMARzBFAiB3J+vUQ/Jy
k7GbBcxSFHukkVeEaj9D2RxMdXuQpfXY7gIhAMcAZtQyyFl1SrUW+wSvFPcjmIHG
1DJ0cfl39mxpRaW7MA0GCSqGSIb3DQEBCwUAA4IBAQBu3dLDywKG7t4JL3mHZLdy
EK22oScmIzitFq7V9+q+b/wPck/djYkE854hMco8mIXGFWYvxNJiarjFd1gynRHa
bNnCGqYvvhYNwl5cw969ANciqgwamYVGG3rzMEMm5EO5X7qatlP3RH0r9BsQlnB3
j3OAD1+xgy9gMLwSzev+poTNFxRRVy5hyH/u8fnVANZi04n6Wkb/hp1Y4XUjl6cQ
OyTFlyOFIqDC5vxWUo5he11abiSx/6NvyaVN5YNH3zvhual4qVpiwGiYqxzOQQDT
+YUJXNID7Ot1LGhfW3V/7Iqgc7XDUBEfpnITff26EByRFXnAC8Ie6XqNUVjtAE4n
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow
MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT
AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs
jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp
Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB
U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7
gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel
/xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R
oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E
BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p
ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE
p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE
AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu
Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0
LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf
r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B
AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH
ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8
S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL
qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p
O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw
UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = dietpi.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2737 bytes and written 386 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: B7DC6CAD69A2A4CEB3186AC6F2754EFEB34A7B4451220E2DCBF55BECE1E7B523
Session-ID-ctx:
Resumption PSK: 90154615130CAC43106CB55CF26621883094D094FAFE0162F20D4ED2638E6D838A4EF7772970EFC3CCB17DE36784275F
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 55 a6 3e 04 01 b1 68 ec-99 5c 00 5c 9c 60 ff de U.>...h..\.\.`..
0010 - b6 ff e3 af 42 0a 5d 21-7d cb 4c 0f cd db cd 3b ....B.]!}.L....;
Start Time: 1619733617
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: AD42105D862F4BB4D598A84523D5B756C8B8A26A1252391C4D5EA5CF7F1AE645
Session-ID-ctx:
Resumption PSK: 23EFEC05D4E31AA55EA53CC7AF5123627EB0879377396AC645B5B6887041D55D65EC51BDA46BAD0E18679D35201E7200
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 88 35 a0 3d 3f 37 4c ba-34 2c ab 8c 7f 73 e5 34 .5.=?7L.4,...s.4
0010 - 95 28 38 f0 1b 51 1e 2b-7f 0e 4e 8e 34 7e 31 f4 .(8..Q.+..N.4~1.
Start Time: 1619733617
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
hmm certificate looks fine
MichaIng
any ideas?
Is the known SSH hosts entry present and correct?
grep 'ssh\.dietpi\.com' /root/.ssh/known_hosts
manilx
April 30, 2021, 12:30pm
16
root@piHole:~# grep ‘ssh.dietpi.com ’ /root/.ssh/known_hosts
grep: /root/.ssh/known_hosts: No such file or directory
Something is wrong…
manilx
April 30, 2021, 12:36pm
17
Copied the file from another server and opted in: fixed!
Okay great, and many thanks for opting in btw. Probably other users read my words/question above so that it was not only knocking down open doors .
Probably worth to write some https://dietpi.com/blog/ post about it .
manilx
April 30, 2021, 12:55pm
19
I’ve opted in all my installations now:
1 pie4
2 VM’s
1 x86
and publish it on all social media channels