https://depot.haiku-os.org/#!/pkg/dmidecode/haikuports/3/1/-/-/2/x86_64?bcguid=bc126-RELW
I does not can select it on my 64bit haiku. But it is good if it is available now, thanks
Thanks! I’ll give it a try.
Hi lelldorin.
Thank you for your works!
Your application System Analysis Tool 64bit version is in the Haiku PM category and not in Haiku PM 64 BIT.
I know, because the 64bit server not available. The first list named “past Haiku with Package Management”, so the 64bit is this too ;-).
You guys collecting the syslog files. The problem is, they can contain informations wich can help to identify the user, or some hints and traces about the user. Like MAC-addresses and other debug outputs.
I think it should be cleaned up or syslogs should not be collected.
Can you explain me the near positions in syslog?
Personal info could be everywhere.
I think you should not collect, store and distribute any syslog, or they should be manually cleaned up.
Some drivers prints mac adresses into the syslog, and while Haiku don’t put any personal info into syslog, any program can push messages into the syslog. Some program can leak usernames or even passwords. Debug programs can be really verbose.
1 Like
Personally, I agree with this. Rather than the SAT tool as it runs today, maybe have a new app or a link in the About box that allows the user to share what they want. After what happened with Facebook, etc. and the new cookie and privacy provisions in the US and EU, it’s important to let users know exactly how their info will be used, even if it is potentially how it may appear or might be used on accident.
Yeah syslog is probably overkill. I think all that’s really needed is device info for video / audio / cpu / networking. There could be a screen that displays each of those items, and then have a checkbox by each one for the user to consent prior to sending.
Ok i should close this project, because syslog is the most importand output for bug reports in the haiku tracker? And then i should delete the sysinfo too. And i does not know that output files have this data included too?
IDK why do you even collects the syslogs, maybe you can explain it.
If you really need them, then:
- at least tell the users that it can contain personal info / credentials, and let the user edit them
- grep the syslog for lines which contains error/fail
- sed the mac addresses out
But i really see no point collecting them at all. What does it contains? You can get the arch, the hw info, the loaded drivers from other sources. The program even asks which hw doesn’t working correctly. Do you really want to have a database with “so looks like a syslog if something doesn’t working”?
Is there a tool to output the syslog based on the event type?
With dmesg (under Linux-based distros), I can do this:
dmesg --level crit,err,warn
That will shorten the output considerably, which helps in both storing and processing that data.
And then there’s inxi in Linux distros, which generates a nice summary of system info and has an option (-z) to hide sensitive data like MACs. Here’s how it looks like:
nicu@Nicu-PC /bigdata/OS/Linux Mint/19 $ inxi -Fxz
System: Host: Nicu-PC Kernel: 4.15.0-23-generic x86_64 (64 bit gcc: 5.4.0)
Desktop: Cinnamon 3.6.7 (Gtk 2.24.30) Distro: Linux Mint 18.3 Sylvia
Machine: Mobo: ASUSTeK model: Z170-DELUXE v: Rev 1.xx Bios: American Megatrends v: 3801 date: 03/14/2018
CPU: Dual core Intel Core i3-6320 (-HT-MCP-) cache: 4096 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 15648
clock speeds: max: 3900 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz 4: 800 MHz
Graphics: Card: Intel Sky Lake Integrated Graphics bus-ID: 00:02.0
Display Server: X.Org 1.18.4 driver: intel Resolution: 1920x1080@60.00hz
GLX Renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2)
GLX Version: 3.0 Mesa 17.2.8 Direct Rendering: Yes
Audio: Card Intel Sunrise Point-H HD Audio driver: snd_hda_intel bus-ID: 00:1f.3
Sound: Advanced Linux Sound Architecture v: k4.15.0-23-generic
Network: Card-1: Intel Ethernet Connection (2) I219-V driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6
IF: enp0s31f6 state: down mac: < filter >
Card-2: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) driver: ath9k bus-ID: 05:00.0
IF: wlp5s0 state: up mac: < filter >
Card-3: Broadcom BCM4360 802.11ac Wireless Network Adapter driver: bcma-pci-bridge bus-ID: 06:00.0
IF: N/A state: N/A mac: N/A
Card-4: Intel I211 Gigabit Network Connection driver: igb v: 5.4.0-k port: c000 bus-ID: 0a:00.0
IF: enp10s0 state: down mac:
Drives: HDD Total Size: 5751.1GB (72.9% used) ID-1: /dev/nvme0n1 model: N/A size: 256.1GB
ID-2: /dev/sda model: ST4000NM0033 size: 4000.8GB ID-3: /dev/sdb model: ST1000DL002 size: 1000.2GB
ID-4: /dev/sdc model: SAMSUNG_HE753LJ size: 750.2GB
Partition: ID-1: / size: 30G used: 20G (70%) fs: ext4 dev: /dev/nvme0n1p1
ID-2: /home size: 162G used: 128G (83%) fs: ext4 dev: /dev/nvme0n1p2
ID-3: swap-1 size: 4.00GB used: 0.00GB (0%) fs: swap dev: /dev/sdb1
ID-4: swap-2 size: 34.36GB used: 0.00GB (0%) fs: swap dev: /dev/nvme0n1p3
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 41.0C mobo: N/A
Fan Speeds (in rpm): cpu: 0
Info: Processes: 338 Uptime: 1 day Memory: 9585.5/31086.7MB Init: systemd runlevel: 5 Gcc sys: 5.4.0
Client: Shell (bash 4.3.481) inxi: 2.2.35
There are different use cases and a single tool can’t cover them all. One of them is bugreports. While it is true that these will require syslogs, they will also require that the user try a fixed driver to confirm it solves the problem, or just try a driver with extra logging. And we already have a dedicated tool for thise which is the Haiku bugtracker. I don’t think the files should be collected elsewhere.
However, there is a second aspectto this project, which is collecting anonymous data about hardware that works. The idea here is to get an idea if a particular laptop is likely towork, relying on other people testing. And also keeping track of the history of what worked in the past and doesn’t anymore.
Ok, do you think it would be enough to delete the syslog files from the database or need i do delete more stuff?
I collect:
- dmidecode output
- ifconfig output
- listdev output
- listimage output
- listusb output
- installed packages
- installed repos
- syinfo output
- syslog output
A lot of this can be considered personal data (about hardware you own, which is the point of the whole thing). miqlas mentionned the new GDPR regulations in EU, and I think it makes sense to follow them, that is, let the user know what is uploaded and let them opt-in for each file that will be sent. If someone has a “secret world domination plan device” connected to their USB bus, they may not want you to know. If another has “secret Skype port I did not release yet” package installed, they may not want it to leak online either. So just let each user decide what can be shared, and what is personal and shouldn’t.