[01:18] <lotuspsychje> good morning to all
[01:20] <sarnold> morning lotuspsychje :)
[01:20] <lotuspsychje> hey sarnold
[01:21] <lotuspsychje> reboot after kernel first :p
[01:22] <sarnold> tomreyn: jfyi :) https://lists.ubuntu.com/archives/ubuntu-release/2019-August/004788.html
[01:25] <tomreyn> sarnold: thanks ;) i noticed it posted earlier in -release
[01:25] <sarnold> woot
[01:26] <tomreyn> i'm already testing live-server
[01:26] <sarnold> hahaha
[01:26] <sarnold> awesome :D thanks
[01:26] <tomreyn> 2 bugs so far, but nothing serious
[01:27] <lotuspsychje> morning tomreyn
[01:27] <tomreyn> good middle of the night, lotuspsychje
[01:27] <tomreyn> or morning, whichever you prefer :)
[01:27] <sarnold> good "I hope your air isn't still on fire"
[01:28] <lotuspsychje> hehe
[01:43]  * tomreyn waiting for 20 snaps to be installed after first boot (which were selected to be installed during installation)
[01:43] <lotuspsychje> uh-oh, more affects on my bug #1838644
[01:49] <tomreyn> carl fletcher also has a clevo
[01:51] <lotuspsychje> oh really
[01:51] <lotuspsychje> tnx for notice tomreyn
[01:51] <tomreyn> model: N7x0WU, (uefi) bios date: 06/11/2018
[01:53] <lotuspsychje> N7x0WU v: 7.009 date: 05/14/2018 mine
[01:54] <tomreyn> same model even, just different bios
[02:04] <lotuspsychje> not sure its related but this came yesterday aswell tomreyn https://bugs.launchpad.net/bugs/1838818
[02:04] <OerHeks> Package: xorg (not installed) ...
[02:05] <tomreyn> lol
[02:05] <OerHeks> just wondered ..
[02:05] <tomreyn> it's also i386 and LXDE
[02:06] <tomreyn> or would be LXDE rather
[02:06] <TJ-> The source package is xorg, but there isn't a binary package of the same name
[02:06] <OerHeks> yes, and response on lotus bugreport is on KDE
[02:06] <lotuspsychje> yeah description isnt the best here lol
[02:06] <tomreyn>  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
[02:07] <sarnold>  Uname: Linux 5.0.0-050000-generic i686
[02:07] <TJ-> [    0.169959] ** You are using 32-bit PTI on a 64-bit PCID-capable CPU. **
[02:07] <lotuspsychje> oO
[02:07] <tomreyn> is that a mainline ppa kernel
[02:08] <lotuspsychje> tested something similiar yesterday
[02:08] <lotuspsychje> 5.0.0-050000rc1-generic
[02:09] <sarnold> status installed linux-image-5.0.0-050000-generic:i386 5.0.0-050000.201903032031
[02:09] <sarnold> is that really a five month old build? or.. I'm very confused
[02:09] <lotuspsychje> not sure this user has it installed though?
[02:09] <lotuspsychje> i was helping bisect
[02:09] <lotuspsychje> *why
[02:10] <OerHeks> i hope not LINUXMINT-19.1/5.0.0-050000-GENERIC/I686
[02:11] <lotuspsychje> heh
[02:12] <lotuspsychje> currently testing Linux Rootbox 5.2.0+ #23 with fastboot=0 and no flickering with the dev
[02:13] <TJ-> I can't see anything wrong in that report, Xorg.log looks fine
[02:14] <lotuspsychje> TJ-: didnt find intel errors in his dmesg neither
[02:14] <lotuspsychje> no underrun like mine
[02:15] <TJ-> lotuspsychje: I wonder if the actual issue is a login loop or similar
[02:16] <OerHeks> with me, it happened before boot, i could perform ctrl alt del to reboot.
[02:16] <lotuspsychje> yeah could be, his description is too vague
[02:17] <lotuspsychje> OerHeks: i only get in trouble on desktop after few sec, at gdm3 and suspend too
[02:17] <OerHeks> i did 2 things, boot with live iso, and fix filesystem that appeared not to have issues, then booting in recovery, dpkg option to fix packages.
[02:27] <OerHeks> i see no simular questions .. https://askubuntu.com/questions/tagged/boot
[10:43] <marcoagpinto> [11:42] <marcoagpinto> Buaaaaaaaa... I didn't go to work... I am depressed
[10:44] <lotuspsychje> drink a cola, it all will be better
[10:44] <daftykins> xD
[10:44] <marcoagpinto> lotuspsychje: I have already drank ~3 litres and no effec
[10:44] <marcoagpinto> effect*
[10:44] <daftykins> aside from you bouncing off the walls?
[10:44] <daftykins> ;)
[10:45] <lotuspsychje> oh, you can mix rum into it :p
[10:45] <lotuspsychje> cuba libre cola!
[10:45] <marcoagpinto> lotuspsychje: I can't drink alcohool because of the medicins I take
[11:24] <jeremy31> lotuspsychje: I tired the 5.0.0-23 kernel and no flickering on this HP laptop
[11:24] <jeremy31> tried
[11:26] <lotuspsychje> jeremy31: ok tnx for the test
[11:28] <lotuspsychje> jeremy31: might be related to clevo panel only?
[11:29] <jeremy31> It could be because of the display used, can you connect to external monitor?
[11:29] <lotuspsychje> jeremy31: didnt test that yet
[11:30] <lotuspsychje> good idea
[11:34] <lotuspsychje> jeremy31: lol, this bug gets even weirder
[11:35] <lotuspsychje> when i type laptop screen gets black
[11:36] <lotuspsychje> and external screen on hdmi flickers
[11:36] <jeremy31> can you switch to hdmi only?
[11:36] <lotuspsychje> when i use mouse, laptop screen is normal
[11:38] <lotuspsychje> hdmi only flickers the tv too
[11:47] <BluesKaj> Howdy folks
[12:34] <marcoagpinto> BluesKaj! Hello!
[12:35] <BluesKaj> hi marcoagpinto
[12:36] <marcoagpinto> BluesKaj: I haven't gone to my weekend job as I am depressed... I spent the whole week working on the thesis, day and night, and I am feeling terrible
[12:36] <marcoagpinto> :)
[12:37] <BluesKaj> have some cola :-)
[12:37] <marcoagpinto> last night I finished another revision
[12:37] <marcoagpinto> I already drank 3,5 litres
[12:37] <marcoagpinto> no effect
[12:37] <BluesKaj> no wonder you feel terrible, that's waaay too much
[12:38] <marcoagpinto> I know... it is so hard to deal with the pression
[15:09] <lotuspsychje> wb TJ-
[15:44] <lotuspsychje> tomreyn: 1838851 looks interesting heh, we might need a dmesg there
[15:45] <tomreyn> lotuspsychje: right thats the bug i was just looking at
[15:45] <lotuspsychje> oh nvm its in log.txt
[15:45] <tomreyn> there's mesg there but of 4.18
[15:45] <tomreyn> *dmesg
[15:46] <lotuspsychje> Linux version 5.0.0-23-generic (buildd@lgw01-amd64-030) in his log.txt
[15:46] <tomreyn> its an amdgpu driven gpu though
[15:46] <lotuspsychje> lets have a look
[15:48] <tomreyn> oh right log.txt, i was looking at dmesg.txt
[15:50] <tomreyn> so this system went into suspend, then power cycled
[15:50] <lotuspsychje> yeah doesnt sound its related to mine
[15:51] <tomreyn> AMD Ryzen 5 2600
[18:04] <lotuspsychje> !info linux-image-generic disco
[18:46] <Kevin199> Hiya
[18:46] <lotuspsychje> Kevin199: what are you looking for in an Os?
[18:47] <Kevin199> I want it to be as fast as possible, I want to click 1 button for email, browser, etc
[18:48] <Kevin199> Preferably run most my services in the terminal
[18:55] <tomreyn> Kevin199: i guess you can do this on either.
[18:58] <tomreyn> the major differences will be that ubuntu goes for more stability, less things breaking, is a more vendor supported / tested platform, whereas arch does not usually hold back on version upgrades, tries to always run the very latest of everything, which probably means more things will break.
[18:59] <tomreyn> personally, i mostly just want my desktop system to work reliably, don't always need the very latest software / features, and if i do i use !HWE and !PPA -s or build it myself.
[18:59] <tomreyn> and on servers i definitely want stability.
[19:00] <Kevin199> I like stability too, I'm very new to Linux so I don't 100% understand the variety in distros
[19:00] <Kevin199> There's so many of them and it's quite bizzare
[19:01] <tomreyn> so to me the tradeoff of going from ubuntu to arch is you get the latest versions faster, at the cost of having to fiddle more.
[19:02] <tomreyn> if you have backups, by all means try more distros, at least a rolling and a non rolling one, and maybe the large ones.
[19:03] <tomreyn> you can do it in a VM but it's not really the same as doing it as your primary OS on your primary computer
[19:05] <Kevin199> I might try Arch in a VM once I figure out the installation process
[19:07] <daftykins> heh oh dear in at the deep end ;)
[19:29] <marcoagpinto> my dear beloved brothers!
[19:40] <wasanzy> Hello
[19:40] <marcoagpinto> hey hey
[19:40] <marcoagpinto> >:)
[19:43] <wasanzy> with the help of tomreyn yesterday I discovered the malware that was consuming the system's CPU at a high rate. In short, the info about the malware is here: https://www.virustotal.com/gui/file/ed3b7209ee905cc5a2a2b33f351511c895ea6913428536b9e162eb487a24528f/detection
[19:45] <wasanzy> I am not able to determine the attack vector yet. Running file /var/lib/postgresql/10/main/postgresq1 output this : https://paste.debian.net/1094265/
[19:47] <tomreyn> hi wasanzy, did your clamav scan bring up any other files?
[19:48] <wasanzy> No
[19:48] <wasanzy> that was the only file it brought out
[19:49] <tomreyn> i think you had not yet an answer to my question of whether the postgrsql server may have been directly accessible from the internet - have you learnt anything about this situation since?
[19:49] <wasanzy> the postgresql server doesn't have direct access from the internet
[19:50] <tomreyn> so you have you checked your firewall configurations and concluded there are no rules / policies set that would allow for this?
[19:52] <tomreyn> i understand that it will have a LAN IP address and is therefore not immediately reachable form the internet, but you never know whether there was a freelancer who 'temporarily' 'needed direct access' so a port forwarding or other firewall rule was set up.
[19:52] <tomreyn> (thus check it)
[19:52] <wasanzy> yes, let me paste you the rules
[19:55] <tomreyn> https://www.postgresql-archive.org/posgresql-log-tp6021877p6021904.html - what we looked at yesterday - also has this statement: "I've also noticed there is a n596tx.so which is not a part of standard installation."  you could search your file system for a file named like this:   sudo find / -type f -name 'n596tx.so'
[19:57] <wasanzy> let me check that
[19:58] <tomreyn> you can also install 'debsums' (apt package) and have it list any files present on this system which deviate from files provided by debian packages at the same location:  sudo debsums -sc
[19:58] <wasanzy> that file does not exist
[20:00] <wasanzy> have you taken a look at the firewall rules?
[20:02] <tomreyn> wasanzy: i missed the private message
[20:02] <tomreyn> looking now, but i'm not that good with iptables
[20:02] <tomreyn> oh this is simple enough, ok
[20:02] <wasanzy> ok
[20:03] <tomreyn> wasanzy: so this server did have a public ip address with no NAT or hardware firewall in front?
[20:03] <wasanzy> yes
[20:06] <TJ-> wasanzy: you can use "sudo dpkg --verify" to verify all package-installed files haven't been conpromised
[20:07] <TJ-> wasanzy: but as I said yesterday the best place to look is the apache web-server log files plus any the application running on apache creates. Knowing what web-applications are being used might help us figure it out
[20:08] <wasanzy> tomreyn: debsums -sc -r /  return nothing
[20:08] <wasanzy> TJ-: OK am running that
[20:08] <wasanzy> I check the nginx logs actually
[20:09] <wasanzy> we don't run apache on the server
[20:10] <TJ-> wasanzy: oh, I thought it was apache. Same thing anyhow... figure out the time frame between which the infection must have occurred then look for clues between those times
[20:10] <TJ-> wasanzy: is the web-application something standard/open-source or custom ?
[20:11] <tomreyn> yes, we should discuss all of the web applicationS
[20:11] <wasanzy> TJ-: https://paste.debian.net/1094270/   that is output of dpkg --verify
[20:12] <wasanzy> The web application is custom build. they are java applications actually
[20:13] <TJ-> wasanzy: is nginx acting as a proxy ?
[20:13] <TJ-> wasanzy: most java web apps uses Tomcat or some J2EE container
[20:14] <tomreyn> i'd also be interested in the output of     ls -l /var/lib/postgresql/10/main/     if you can share this
[20:14] <TJ-> wasanzy: you need to run that command as root (sudo) so it can access everything... but generally most changes under /etc/ will be local admin config changes... but its worth triple-checking
[20:15] <wasanzy> Nginx is serving as a proxy. the app is a stand-alone no tomcat
[20:15] <tomreyn> we could also search for all files changed since when the intrusion likely happened. we know the miner started yesterday, which means it must have been before then, but we do not yet know any more than that
[20:16] <wasanzy> https://paste.debian.net/1094271/
[20:17] <wasanzy> tomreyn: miner started on the 1st of August, thus 3 days a go
[20:18] <tomreyn> thanks for clarifying
[20:18] <TJ-> wasanzy: so should be easier to track how it got added then
[20:19] <TJ-> wasanzy: I presume your web-application (Java) is using raw SQL statements in talking to Postgresql ?
[20:20] <wasanzy> unless I confirm from the developers
[20:20] <TJ-> wasanzy: so at some point I'm guessing that some front-facing public form input is not being sanitised and is able to add arbitrary SQL commands with a "; ..." - this would explain how/why the malware executes as the postgres user account
[20:21] <wasanzy> the only entry to the db to the best of my knowledge is user/password login on the app
[20:22] <tomreyn> wasanzy: please also show    stat /var/lib/postgresql/10/main/postgresq1    and     getfattr --dump /var/lib/postgresql/10/main/postgresq1
[20:24] <tomreyn> getfattr is provided by the    attr    package
[20:25] <TJ-> wasanzy: I really wouldn't keep that server operating. I'd replace it with a known clean backup
[20:26] <TJ-> wasanzy: you can always keep the VM alive for forensics but right now you're risking whatever business/service relies on it
[20:26] <wasanzy> tomreyn" https://paste.debian.net/1094274/
[20:27] <tomreyn> TJ-: i'm not sure this info got to you the other day, but root owned audit logs in /var/log/audit* were also deleted. so worst case the fact the miner was postgres owned could be an attempt to mislead.
[20:28] <wasanzy> TJ-*: The server is no more processing services, taken it off yesterday
[20:28] <tomreyn> wasanzy: i second this, you should really not boot this system anymore. you should only access the file system from a frehly installed ubuntu system.
[20:29] <wasanzy> tomreyn: I can only access the server remotely
[20:29] <TJ-> tomreyn: really? you're sure of that?
[20:30] <wasanzy> user.xdg.origin.url="http://<IP_ADDRESS>/post0120/post" could this mean this is the source of the malware?
[20:30] <TJ-> wasanzy: It's Linode I noticed, so you could access the VM through the Finnix recovery option
[20:30] <tomreyn> yeay
[20:30] <tomreyn> exactly
[20:31] <tomreyn> this server is down, though
[20:31] <wasanzy> tomreyn: were you referring to my question?
[20:32] <wasanzy> I mean the source of the malware question
[20:32] <tomreyn> wasanzy: yes, postgresq1 was downloaded from http://<IP_ADDRESS>/post0120/post using wget (unless this information was falsified)
[20:33] <tomreyn> another VULTR system.
[20:34] <wasanzy> which could mean the attacker got access to our system and used wget to download?
[20:35] <tomreyn> sure, that's the hypothesis i'm operating on since reading https://www.postgresql-archive.org/posgresql-log-td6021877.html yesterday
[20:37] <tomreyn> wasanzy: back to the point that you should not be booting this server anymore: we have to assume ti was rooted. after that, a rootkit may have been installed. you can no longer know what this system does, it may spread malware further in your network, and on the internet. it may have logged your login credentials when you logged in using ssh. and worse.
[20:41] <tomreyn> other approaches i can think of now is to see if you can use undeletion utilities to recover files from /var/tmp and /var/log
[20:41] <tomreyn> and to look for suid + sgid files across the entire file system
[20:42] <tomreyn> i mean across all the file systems
[20:43] <wasanzy> if what I pasted here is true: https://paste.debian.net/1094274/ then my case is the same as https://www.postgresql-archive.org/posgresql-log-td6021877.html
[20:44] <wasanzy> tomreyn: do you have any undeletion utility in mind?
[20:44] <wasanzy> note: I rebooted the system
[20:45] <tomreyn> which file system do you hav there?
[20:46] <tomreyn> extundelete for ext3/4
[20:46] <tomreyn> or ext4magic
[20:47] <tomreyn> here, too, you introduce more problems by running the server from the original installation: you're overwriting data, making data recovery much less likely
[20:48] <tomreyn> whenever you do forensics, any possibly compromised storage locations must only be mounted read-only.
[20:51] <wasanzy> ext4
[20:51] <TJ-> wasanzy: if it was me I'd create a local guest VM with the same release/architecture and  packages as the Linode, then use rsync to copy from Linode all the *changed/different* files and log which files are transferred by rsync. Then I can test the identical set-up locally AND know which files need checking
[20:55] <tomreyn> sorry TJ, i somehow missed this, thought you were asking wasanzy for confirmation. what were you referring to here? <TJ-> tomreyn: really? you're sure of that?
[20:55] <TJ-> tomreyn: sure something deleted audit logs?
[20:55] <TJ-> tomreyn: because those same messages will be in the journald logs
[20:55] <tomreyn> that's what wasanzy implied
[20:56] <tomreyn> i think he said that audit logs are in /var/(log/audit* but those logs are missing for the very day the intrusion occurred.
[20:56] <tomreyn> if they're also in the systemd journal this should be investigated
[20:57] <wasanzy> how do I find them in the system journal?
[20:58] <tomreyn> journalctl is the utility used to access those logs
[20:58] <TJ-> wasanzy: which ubuntu release is it?
[20:58] <wasanzy> 18.04
[20:59] <tomreyn> i think you said 18.04.2 fully up to date yesterday?
[20:59] <wasanzy> yes
[20:59] <tomreyn> journalctl --list-boots    could be of interest to tell which uptime the system had
[20:59] <TJ-> wasanzy: try "journalctl -u auditd.service"
[21:00] <tomreyn> maybe also --verify to see if there's anything missing
[21:00] <TJ-> wasanzy: it could depend on how auditd configures its logging
[21:02] <wasanzy> Aug 01 18:47:34 minex360-linode-prod-1 systemd[1]: Stopping Security Auditing Service...
[21:02] <TJ-> well, I have to go out. It's almost midnight and we've just started combining the oil-seed rape
[21:02] <wasanzy> I think that was when I rebooted the server
[21:02] <wasanzy> thanks a lot TJ-
[21:03] <TJ-> "minex360-" ? ironic!
[21:06] <tomreyn> good luck on the old-seed rape.
[21:06] <tomreyn> brinmg flashlights
[21:08] <wasanzy> tomreyn: --verify is running
[21:09] <tomreyn> this can take a while. can you show the latest boots, too?
[21:13] <wasanzy> https://paste.debian.net/1094280/   -> ---verify
[21:15] <tomreyn> so they seem to be complete, or coherent
[21:15] <wasanzy> reboot   system boot  4.15.0-55-generi Thu Aug  1 18:49   still running
[21:17] <tomreyn> wasanzy: that's just the latest boot. the ones before that would be more interesting
[21:19] <wasanzy> last reboot => that is the only entry returned
[21:20] <tomreyn> by --list-boots ?
[21:22] <tomreyn> what you posted lookd more like output of the "last" command
[21:22] <tomreyn> so sourced from /var/log/wtmp
[21:22] <tomreyn> but i'm asking about the output of    journalctl --list-boots    which would provide output in a different format
[21:24] <wasanzy> ext4magic -m  -d /var/log
[21:25] <wasanzy> -1 36e9fc446ca743de91fc3aeafa76b2eb Mon 2019-07-29 12:00:01 UTC�<80><94>Thu 2019-08-01 18:47:34 UTC
[21:25] <wasanzy>  0 ad41338ef7424c76a7f1ba629918d6c9 Thu 2019-08-01 18:49:23 UTC�<80><94>Sat 2019-08-03 21:24:22 UTC
[21:26] <wasanzy> ext4magic -m  -d /var/log => doesn't seem to be recovering anything
[21:29] <tomreyn> wasanzy: you did not specify the file system to operate on, see <filesystem> on the ext4magic man page
[21:29] <tomreyn> wasanzy: are those the only boots    journalctl --list-boots    reported, or the only ones you shared with us?
[21:29] <tomreyn> it'd help to get a bit more context from you in general.
[21:30] <wasanzy> the only ones reported
[21:30] <tomreyn> ok
[21:33] <tomreyn> wasanzy: can you share the full log from boot -1 using    jounrctl -b -1 | nc termbin.com 9999     or, if that's not an option (I'd understand), can you share this:    journalctl -b -1 | grep 'Linux version'
[21:33] <tomreyn> sorry, the first command was     journalctl -b -1 | nc termbin.com 9999
[21:33] <wasanzy> ext4magic /dev/sda3 -R -a $(date -d "-5day" +%s)  => you think this could help?
[21:35] <wasanzy> jounrctl -b -1 | nc termbin.com 999 => no output
[21:35] <wasanzy> journalctl -b -1 | grep 'Linux version' => no output
[21:35] <tomreyn> wasanzy: you missed one 9
[21:36] <wasanzy> journalctl -b -1 | nc termbin.com 9999 => no output
[21:36] <tomreyn> so this would post the log from    Mon 2019-07-29 12:00:01 UTC till  Thu 2019-08-01 18:47:34 UTC online:    journalctl -b -1 | nc termbin.com 9999
[21:37] <tomreyn> hmm weird
[21:37] <tomreyn> if you just run this?    journalctl -b -1
[21:38] <tomreyn> maybe some logs were actually deleted there, too. can you show    ls -lahR /var/log/journal/  | nc termbin.com 9999
[21:39] <wasanzy> journalctl -b -1 => print a lot of entries
[21:39] <wasanzy> https://termbin.com/0zw9
[21:41] <tomreyn> wasanzy: the output of     journalctl -b -1      may copntains logs on what the intruder did, and which they failed to delete.
[21:42] <wasanzy> ok I will look a that
[21:42] <tomreyn> the oldest system logs you still have are from   Jul 29 18:24
[21:43] <tomreyn> what does this say ?    getent passwd postgres
[21:43] <wasanzy> am trying to run this: ext4magic /dev/sda -R -a $(date -d "-4day" +%s)
[21:44] <wasanzy> postgres:x:111:116:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
[21:46] <tomreyn> okay this looks normal
[21:48] <wasanzy> ok
[21:49] <wasanzy> ERROR: can not use "RECOVERDIR" for recover directory. It's the same filesystem : "/dev/sda"
[21:49] <tomreyn> right, this is an intelligent utility, it would not write data to the same storage it is trying to recover data from.
[21:50] <tomreyn> after all, thois could prevent recovery of this data
[21:50] <tomreyn> can you tell when this server was actually installed? the oldest journalctl logs date back to only 2019-06-29
[21:51] <wasanzy> the server was installed before I even joined the organization last year
[21:58] <tomreyn> how much disk space is there available on /var/log?    df -h /var/log
[21:59] <wasanzy> 117G
[22:01] <tomreyn> systemd will automatically delete old logs when it reaches certain storage thresholds. in your case, it reached the 4 GB fixed threshold, thus old system logs are gone
[22:01] <tomreyn> apparently this system was really logging a *lot*
[22:01] <tomreyn> more than ususal
[22:02] <wasanzy> am coming to boot into rescue mode
[22:03] <tomreyn> it created 10 log files each sized 128 MB *after compression* per day
[22:03] <wasanzy> right
[22:03] <tomreyn> this suggests something was not properly configured / misbehaving in the first place.
[22:04] <tomreyn> as you can surely see when looking at   journalctl -b -1 -e
[22:04] <tomreyn> (-e goes to the end of the log period)
[22:05] <wasanzy> output starts from Aug 01
[22:07] <tomreyn> i assume you can't share this log?
[22:09] <TJ-> whatever the custom java web-application is I'd expect it to be using the java.logger interface to do its own logging, which might be a better place to investigate
[22:12] <Ben64> bleh, still no window controls in chrome
[22:12] <Ben64> not sure what update broke it, but it's kinda annoying
[22:16] <tomreyn> TJ-: we do have audit logs via journalctl starting Aug 01, but i don't know how to work with them
[22:16] <tomreyn> (also this may well be too late)
[22:17] <TJ-> tomreyn: if the attack vector is the java web-app > postgresql raw SQL input, then I'd put more reliance on the java-app's own logs (if it does log!)
[22:17] <wasanzy> TJ-: Yea the java app has logs. I can see a lot of direct sql statements in the logs. "Select statements though"
[22:17] <tomreyn> selects would work
[22:18] <tomreyn> select * into outfile (i think this is mysql specific, not sure, but postgres may have something similar)
[22:19] <TJ-> wasanzy: I'd look for anything matching the regexp "..*;[^$]" (in other words, any statement that has a semi-colon NOT at the end of the line
[22:19] <TJ-> wasanzy: that'd mean the bit after the semi-colon was an additional statement, which if raw input is allowed, would be the obvious vector
[22:19] <tomreyn> that's %3B or %3b is url encoded
[22:19] <tomreyn> that's %3B or %3b IF url encoded
[22:20] <TJ-> wasanzy: the other possibility is the java application itself, and whatever user account it runs as, is compromised
[22:21] <TJ-> this assumes it's a high level attack via services and not a kernel-level compromise
[22:24] <wasanzy>  zgrep  "..*;[^$]" /path/to/logdir/* | grep -i "SELECT"
[22:26] <wasanzy> nothing yet
[22:28] <TJ-> wasanzy: I'm not guaranteeing my syntax was correct!
[22:30] <TJ-> seems to work in a test though:  echo -e "select * from table where x=y;\nselect * from table where x=y;select input >/var/tmp/test" | grep '..*;[^$]'
[22:34] <wasanzy> yea I got some outputs but not much to think is a hack. looks like some exceptions
[22:35] <tomreyn> how about nginx logs, it would onl yhave GET requests logged though, and only if you did log succesfull requests.
[22:37] <wasanzy> I could look for post requests though
[22:38] <tomreyn> those wouldn't be logged by a web server normally
[22:40] <tomreyn> it appears that the "search" web app allows for self-registration, possibly providing extended access?
[22:43] <TJ-> ? did we find out what the web-application is?
[22:44] <tomreyn> i did find some, i think
[22:44] <tomreyn> but won't discuss it unless wasanzy wants me to
[22:44] <tomreyn> he passed me some syslog in private
[22:48] <wasanzy> TJ- and tomreyn: I shared paste in private with you two
[22:49] <wasanzy> Please study that and see if you can make any sense out of it
[22:50] <tomreyn> thats sshd, running as root, accessing /etc/passwd to verify a connecting user exists
[22:50] <tomreyn> ...i think
[22:50] <TJ-> wasanzy: ahhh, I have messages blocked
[22:50] <wasanzy> blocked?
[22:50] <wasanzy> you mean you blocked private messages?
[22:50] <TJ-> wasanzy: Yes
[22:51] <wasanzy> ok
[22:51] <tomreyn> a rather common setup actually ;)
[22:51] <TJ-> wasanzy: otherwise people think they can bother me for personal support constantly
[22:52] <wasanzy> ok
[22:52] <tomreyn> TJ-: did you receive those 5 lines from syslog since? they give away the server's public IP address, which you can then use to determine the application host names based on the SSL certificate on 443
[22:53] <tomreyn> (HTTPS)
[22:53] <TJ-> tomreyn: no, and I have to go anyhow, we're working through the night
[22:53] <tomreyn> yes, you said so, ok, was just wondering
[22:54] <TJ-> I've been in and out as the loads arrive from the combine
[22:54] <tomreyn> cool
[22:56] <tomreyn> wasanzy: so i registered a new user on the 'search' web app, and was then able to connect a database to it. i connected the postgresql database on <IP_ADDRESS> (the server itself) , authenticating as the postgres user. tested the connection - it succeeded.
[22:56] <tomreyn> it doesn't seem possible to exfiltrate data this way directly, but this is probably not sound.
[22:58] <tomreyn> oh actually i can access all databases
[22:58] <tomreyn> and exfiltrate data
[22:58] <wasanzy> that is my server?
[22:58] <tomreyn> so i'll stop here
[22:59] <tomreyn> the one which is now running at the ip address listed as the ssh server destination in the latest log excerpt you shared
[22:59] <tomreyn> i assume this is the replacement production server you setup?
[23:01] <wasanzy> no
[23:01] <tomreyn> ahem, actually thios hostname points to a different server of the same organization. i'll send you details in private message.


[01:16] <canthus13> thafreak: What was I ignoring?
[01:45] <canthus13> ronnoc: ..Do you happen to do dag?
[03:46] <ronnoc> canthus13: hello! dag?
[03:47] <canthus13> ronnoc: guess not.
[03:47] <canthus13> there's a Ronnoc in my dag group.  Chromium is only using 2 GB of memory. I think it's broken.
[13:09] <andygraybeal> canthus13, my server cabinet
[13:09] <andygraybeal> the sensor is at the butt-end of the fans of the machines.
[13:09] <andygraybeal> i wonder if that is a bad or good place for it, for one.. and next, what is a good critical alert temperature?
[13:14] <canthus13> ah.
[13:14] <canthus13> I dunno.
[13:14] <canthus13> I mostly rely on proc temp.
[13:21] <andygraybeal> cool.
[13:22] <canthus13> ...or hot. :)
[13:24] <andygraybeal> hehhehe
[13:57] <thafreak> andygraybeal: i think it's supposed to be in front, or where ever the fans pull air in at
[13:57] <thafreak> i think you want to know temp of air going into the machine
[13:58] <andygraybeal> thafreak, awesome thank you for saying
[13:58] <andygraybeal> aah wonderful
[13:58] <thafreak> atleast, i think that's what the guys over in CS dept do...
[13:58] <andygraybeal> thafreak, i trust you, but is there any documentation on this?
[13:58] <thafreak> i'm pretty sure the sensors are stuck to the door
[13:58] <thafreak> maybe, i'm going off memory :)
[13:59] <andygraybeal> yea, i have mine attached to the rear door.. .the outflow area, not the intake.  awesome thank you for saying that.
[13:59] <andygraybeal> i will try and a source with the same information
[14:00] <thafreak> canthus13: you missed the link i posted here with a screenshot of the number of tabs my chromium browser has open
[14:00] <thafreak> congrats on the baby by the way...everything healthy?
[14:00] <thafreak> mom doing ok?
[18:21] <andygraybeal> wake up wake up
[18:21] <paultag> nah
[18:21] <andygraybeal> ;)


[03:01] <drhalan> is gcc5 starting to land in main? :)
[08:01] <lordievader> Good morning.
[10:18] <alkisg> Hi, in wily, in vt-1, instead of utf-8 I'm seeing things like this: ls: Î±Î´Ď…Î˝Î±ÎĽÎŻÎ± Ď€ĎĎŚĎÎ˛Î±ĎÎ·Ď‚ Ď„ÎżĎ… asdf: Î”ÎµÎ˝ Ď…Ď€Î¬ĎĎ‡ÎµÎą Ď„ÎĎ„ÎżÎąÎż Î±ĎĎ‡ÎµÎŻÎż Î® ÎşÎ±Ď„Î¬Î»ÎżÎłÎżĎ‚
[10:18] <alkisg> That's the equivelant of greek utf-8 messages if they're considered cp1250 instead
[10:19] <alkisg> Is that a regression due to systemd? Known issue? Any workarounds?
[10:26] <alkisg> The problem is in /etc/default/console-setup, it has CHARMAP="ISO-8859-15" instead of CHARMAP="UTF-8"...
[10:26]  * alkisg wonders who changed that, 15 years after all distros had switched to utf-8....
[10:32] <lordievader> Hmm, interesting.
[10:33] <lordievader> alkisg: Here (Kubuntu) it is set to UTF-8...
[10:34] <alkisg> lordievader: ah, thank you, let me see if it only affects unity+flashback...
[10:37] <alkisg> wily mate => ISO-8859-15 in the live cd
[10:38] <alkisg> console-setup 1.108ubuntu5
[10:38] <alkisg> lordievader: which console-setup package version do you have, please?
[10:39] <lordievader> alkisg: 1.108ubuntu5
[10:39] <alkisg> Is Kubuntu using ubiquity as the installer?
[10:39] <lordievader> Yes.
[10:39] <alkisg> Hrm
[10:40] <alkisg> lordievader, do you remember which installation media did you use, e.g. maybe 1 month ago?
[10:40] <alkisg> Maybe it had an older console-setup version at that time...
[10:40] <alkisg> wily unity => same issue, downloading kubuntu daily build...
[10:42] <lordievader> I can't remember how I installed it, it might have been an upgrade.
[10:45] <alkisg> Kubuntu daily build.iso also has the same issue
[10:49] <lordievader> Hmm, guess it was an upgrade then.
[10:49] <lordievader> File a bug ;)
[10:50] <alkisg> In my experience, filing bug reports is a complete waste of time
[10:50] <alkisg> They never get resolved in Ubuntu unless you already have a patch AND ping the package maintainer :)
[10:50] <alkisg> So I'm trying to do that, before filing the bug report...
[11:01] <fabrizziop> is it safe to dist-upgrade now with gcc5?
[11:02] <lordievader> For testing, yes. For production, its a development release... No.
[11:33] <alkisg> The problem was there in 15.04 as well, checking 14.04...
[11:34] <lordievader> I upgraded that box all the way from Trusty ;)
[12:23] <BluesKaj> Hiyas all
[13:51] <soee> when will Firefox get update to latest verion ?
[13:53] <k1l_> firefox 40 is in proposed
[13:55] <soee> k1l_: ok, thank you


[07:27] <ochosi> morning everyone
[07:27] <elfy> hi ochosi
[07:28] <ochosi> hey elfy
[07:43] <elfy> that's the package tracker set up and the testers told :)
[08:03] <jhenke> morning folks, did anybody of you saw https://bugs.launchpad.net/ubuntu/+source/indicator-printers/+bug/1293606 already? just happened to me as well on the trusty work system
[08:03] <elfy> nope - but printer's nto working at all in unicorn
[08:06] <jhenke> okay, so it seems printing is in need of some attention
[10:00] <brainwash> but we use the printer-applet and not indicator-printers
[10:02] <brainwash> these extra unity indicators tend to be somewhat broken or badly integrated =S
[11:05] <jhenke> good to know, the unity indicators have a more speaking name though
[11:06] <brainwash> jhenke: I've reassigned the report, because after taking a closer look it seems to be clear, that indicator-printers is not being used in this case
[11:07] <jhenke> brainwash: sure, I just want to point out the obvious temptation to think it would be the other package
[11:09] <brainwash> I'm also pretty sure that someone has bothered me with this issue some time ago
[11:09] <brainwash> it's a python app after all, these are sometimes poorly coded :)
[11:13] <ochosi> hey Logan_
[13:08] <elfy> seem to be a lot of mails in the -devel list of late that are support issues
[13:11] <ochosi> yeah
[13:11] <ochosi> that sucks quite a bit
[13:11] <elfy> new XPL should stamp their mark on that list with a big foot on Friday
[13:12] <elfy> bluesabre: you can read that too ^^
[13:12] <elfy> :)
[13:12] <elfy> assuming we have a new one on Friday
[13:17] <ochosi> yeah, otoh one angry mail won't change things quickly
[13:17] <ochosi> and more moderation is extra work
[13:19] <elfy> yep
[13:19] <elfy> there is that
[13:19] <elfy> not easy to moderate m/l methinks
[13:27] <ochosi> that is actually one point for or against having a sub-list for -team
[13:27] <ochosi> less need to moderate dev as the really important stuff gets discussed/decided on -team
[13:28] <ochosi> so -team actually becomes the new -dev, but it's a closed list (in terms of who can write)
[13:29] <elfy> not sure that's a point against having a -team list
[13:30] <elfy> if we just kept -devel - then if something came along that needed -team to vote on and 200 replies turned up - would you want to count the -team votes?
[13:31] <elfy> imo we need something that's usable at any time - m/l being an option - that we know isn't going to have replies to it that are not needed
[13:33] <ochosi> well, what i meant was:
[13:33] <ochosi> yes, we will have a clean list because only we can write on it
[13:33] <ochosi> but ppl could consider it as elitism (i think knome mentioned that at some point) because the list is closed
[13:34] <ochosi> but personally, i think that doesn't matter, we could use a closed space to talk
[13:34] <ochosi> and ppl can still read
[13:34] <ochosi> and become team members or show up at meetings (which are open too)
[13:55] <elfy> well as far as elitism is concerned - team is :)
[13:55] <elfy> it's not closed though :)
[14:03] <knome> i personally think that it is at least highly annoying that there are non-development related posts in the -devel list
[14:03] <knome> and whether we actually created a new list or not, i *still* think those should be forwarded to users
[14:03] <knome> or simply make -devel only for team members to post
[14:04] <knome> people can always keep complaining how stuff is "exclusive"
[14:04] <knome> but that's not a valid point as long as the mail they are trying to send is unsuitable for the list
[14:06] <elfy> I'd have thought that forwarding to -devel would be more suitable
[14:06] <knome> yes, i'd rather have everything initially go to -users
[14:06] <elfy> why?
[14:06] <knome> well here's the thing
[14:07] <knome> i can't see any way we can make non-devel-related issues stop on -devel
[14:07] <knome> unless we block all mails except from those from team (and other explicitly trusted emails)
[14:08] <knome> it's much better to have a relatively devel-related issue on users
[14:08] <knome> than to have a firefox support issue on devel
[14:08] <elfy> so close -devel completely
[14:08] <elfy> ?
[14:08] <knome> no
[14:08] <knome> make -devel the "team" list
[14:08] <elfy> mmm
[14:08] <knome> and moderate all mails not from team
[14:08] <knome> and tell everybody to send to -users
[14:08] <knome> or in special cases, allow them to send to -devel
[14:09] <knome> that is, explicitly specify it's ok
[14:09] <elfy> ok - I can see that
[14:09] <knome> the majority of the fuzzy mails are generated by threads started by non-team members
[14:09] <knome> eg. "i want libreoffice"
[14:09] <elfy> need more mods for list then
[14:09] <knome> then it turns into a flamewar or otherwise just an irrelevant thread
[14:09] <knome> we need more moderators anyway
[14:10] <elfy> I don't mind doing that
[14:10] <knome> i can list several people who i'm happy to give the mod access right away
[14:10] <elfy> if we go that way
[14:10] <knome> right, would you be willing to do it regardless what we decide about the lists?
[14:10] <knome> because if yes, i'll drop you in the moderator list right now
[14:10] <elfy> yea I don't mind doing that
[14:11] <knome> ok
[14:11] <knome> let me get you the details soon
[14:11] <elfy> ok
[14:11] <elfy> I know how to - the FC list is closed
[14:11] <elfy> everything to that is moderated
[14:11] <knome> yeah, i mean passwords and such ;)
[14:12] <elfy> yep
[14:12]  * elfy hates m/l password - they all get confused with each other ...
[14:12] <knome> heh
[14:15] <knome> so yay
[14:16] <knome> i'm really interestes how this mailing list stuff goes
[14:16] <knome> i want to cut down my influx of mail now that i don't actually need to monitor it all
[14:17] <elfy> :)
[14:18] <elfy> all that said - this won't help the need in my opinion for something like trello
[14:18] <knome> yeah, i understand
[14:18] <knome> they are two completely different things
[14:18] <elfy> what it will mean is I don't need to bother with forestpiskie
[14:18] <knome> ;)
[14:18] <elfy> if it's important enough for me to know when I'm not here it should be elsewhere :)
[14:19] <knome> :)
[14:19]  * elfy is sitting here wondering why the testcase for xfdesktop settings is so completely wrong ...
[14:20] <knome> is the testcase written for 4.10?
[14:20] <elfy> I think it's probably written for something older than Moses :p
[14:21] <elfy> anyway - good job we're going through them :p
[14:21] <knome> hehe
[14:21] <knome> yep
[14:28] <ochosi> hehe, i step away for a few mins and knome makes my point for me :)
[14:28] <elfy> :)
[14:28] <ochosi> so yeah, +1 on making -devel the new -team list
[14:29] <ochosi> simply because creating another list when we already have one blows
[14:37] <elfy> well stopping people who can currently post to it wasn't something I'd thought of doing tbh
[14:39]  * ochosi thinks it's a sane consequence
[14:39] <elfy> yea agree - if we want to do that rather than create a new one
[15:51] <knome> elfy, we can send them a moderation message that explains the situation and suggests them to post the -users list
[15:54] <elfy> yep
[17:15] <slickymasterWork> https://code.launchpad.net/~elfy/ubuntu-manual-tests/XFCEOptional/+merge/218310 <- on it, elfy
[18:30] <ali1234> ochosi: wait, so i won't be able to post to -devel?
[18:40] <brainwash> ali1234: join the team, problem solved :)
[18:53] <amigamagic> sorry for the intrusion guys, but it's possible to "approve"/"disapprove" an user when he want to register for a devel mailing list?
[18:55] <amigamagic> I mean, if you can write to a mailing list without approval from anyone, then it's normal that you will have unwanted messages too
[18:56] <amigamagic> but if you should have to "approve" an user as developer before he could send its mails to the devel list, then the user would think more than 2 times, before send an email in that list
[18:57] <ochosi> ali1234: we haven't discussed this very deeply yet, but the goal of that other (new, additional) list we were discussing was actually designed to get us a cleaner -devel list
[18:57] <ochosi> instead of creating a new one, i personally think we should just clean up the devel list and make it more focussed again
[18:57] <ochosi> too many emails that are crypto-bugreports or wishlist-entries (or rants)
[18:58] <ochosi> so stuff that is not really helpful for or related to development
[18:58] <ali1234> okay but this doesn't answer my question :)
[18:58] <amigamagic> have you considered a forum?
[18:59] <ali1234> developers don't like forums
[18:59] <ochosi> ali1234: well, there is no single yes/no answer yet, i presume we'll discuss this more and maybe even take a vote on this
[19:00] <amigamagic> ali1234, why?
[19:02] <ali1234> they don't have threading, they are a pita to search, posting code requires using obscure escape codes, you need yet another login, forum warriors, mega-threads, stupid "don't post a new thread" rules,
[19:04] <ali1234> the annoying animated avatars and sigs, inability to reply inline easily, you have to use a web browser to access them
[19:04] <ali1234> you can't have any control over the user interface because you are stuck with whatever braindead html the creator chose
[19:05] <ochosi> hehe
[19:05] <ochosi> nicely said
[19:05] <ali1234> and of course don't forget that because it's html, you have to GET and POST which means the UI is guaranteed to suck and lose your post you spent half an hour writing
[19:05] <ali1234> eg if you accidentally click back, or another link
[19:09] <amigamagic> :O
[19:10] <amigamagic> I think you have been a little bit exaggerated on the matter, but I understand many things you said. :)
[19:18] <ochosi> ali1234: anyway, i guess this channel our primary form of communication either way
[19:20] <ochosi> and as brainwash suggested, you can always join the team ;)
[19:20] <amigamagic> what exactly means "join the team"? :)
[19:24] <ochosi> it means contribute consistently for a while, let the others in the team get to know you a bit, and take responsibility (or something like that)
[19:25] <sidi-valencia> it means there's a group of individuals bound by some sort of tacit social rule (usually a common objective), that causes them to identify themselves as being such a group, and joining the team refers to you abiding by the same tacit rules and identifying yourself in the same way as them and them accepting that you do so
[19:25]  * sidi-valencia is done trolling here.
[19:25] <ochosi> hehe
[19:27] <ochosi> bbl
[19:27]  * amigamagic is going to eat very much to restore its mental forces after sidi-valencia answer
[19:29] <sidi-valencia> It means you can kick people like out of the team's boundaries and on the other side of the geographical representation of said boundaries, too.
[19:29]  * sidi-valencia likes to say ******
[19:40] <ali1234> we got a breakthrough on that thunar bug... someone found steps to 100% reproduce it
[19:43] <elfy> ali1234: did you miss this bit of the m/l discussion "unless we block all mails except from those from team (and other explicitly trusted emails)"
[19:43] <ali1234> i didn't read any of that, just going on what i read here
[19:43] <elfy> that is here
[19:44] <ali1234> oh, well i missed it then
[19:44] <elfy> I guessed so :)
[19:45] <knome> ali1234, if we decide to limit the -devel list for team members only, we can obviously allow non-team members too, with consideration
[19:46] <knome> ...and we probably should, because not everybody that can give us insightful messages is on the team
[19:46] <knome> we've allowed mails from non-subbed ubuntu/canonical employees through before, we can continue with the same mindset
[19:51] <jhenke> ali1234 do you mean the "fork before gkt_init()"?
[19:51] <ali1234> with thunar? no, that's definitely not it
[19:51] <ali1234> with the new method i can crash it without daemon mode
[19:53] <jhenke> okay, just saw that mail today on the xfce-dev ML and thought you might mean it
[20:18] <amigamagic> ali1234, what thunar bug?
[20:19] <ali1234> bug 1203296
[20:29] <amigamagic> yeah, I too can reproduce it
[20:29] <amigamagic> at first I couldn't reproduce it because if you click on the eject little icon it works
[20:37] <elfy> slickymaster: thanks :)
[20:48] <ali1234> hmm
[20:49] <ali1234> hmm.... okay... system has gone really strange
[20:56] <ali1234> okay, getting somewhere. it still crashes with G_SLICE=always-malloc
[20:57] <ali1234> G_SLICE=debug-blocks doesn't catch any early errors
[20:59] <sidi-valencia> is it 100% reproducible?
[20:59] <ali1234> it is for me
[20:59] <ali1234> i have not quite nailed down exactly which steps are required yet though
[21:00] <ali1234> the procedure is a bit long winded
[21:03] <ali1234> basically you need an unmounted drive eg a usb drive (and it might have to be a usb drive)
[21:04] <ali1234> then you mount it, open a file on it, attempt to unmount it twice, close the file, unmount it for real, then quit thunar. it will segfault
[21:04] <elfy> ali1234: that might be why I can't reproduce it now - usb sticks only
[21:04] <ali1234> what do you mean exactly?
[21:05] <elfy> "it might have to be a usb drive"
[21:05] <ali1234> did you try it with mounting a non-usb drive?
[21:06] <ali1234> wait, i can try it
[21:06] <elfy> I've got none
[21:06] <elfy> oh - would a partition do it?
[21:06] <ali1234> i dunno, that's the question :)
[21:06] <ali1234> "eject" does not trigger the bug
[21:06] <elfy> not sure if I could umount the other drive completely
[21:06] <ali1234> only "unmount"
[21:07] <ali1234> okay confiit worked with a fixed SATA disk partition
[21:07] <elfy> ok
[21:08] <ali1234> probably it will happen with anything that gets mounted, eg gvfs network shares (seen reports of that)
[21:09] <elfy> so - mount - open something from it - unmount - close error dialogue - close opened file - unmount
[21:11] <elfy> yep - crashed
[21:11] <ali1234> i always have to do it twice but i think "where thunar thinks it is" affects the result
[21:12] <ali1234> where is the highlight in the sidebar when you close thunar?
[21:12] <elfy> just did it the once and it's started apprt
[21:12] <elfy> hang on - I'll do it again
[21:13] <elfy> after closing the error dialogue the sidebar highlight has defaulted to my home in places
[21:13] <ali1234> and it crashes?
[21:13] <ali1234> hmm... well, so much for that theory
[21:13] <elfy> yep
[21:13] <elfy> twice now
[21:14] <elfy> that's with an unmounted fixed drive partition
[21:14] <elfy> any point in me sending this bug report - it's in Unicorn
[21:15] <ali1234> none at all
[21:15] <elfy> thought as much :)
[21:17] <ali1234> uploading a video of me reproducing it
[21:17] <ali1234> it's easier than telling exactly every single step i do
[21:18] <elfy> ok - I'll follow it tomorrow when I'm more awake
[21:18] <elfy> I'm notoriously bad at following video's ...
[21:19] <ali1234> heh
[21:19] <ali1234> if i try to write every single step i'll just forget something important
[21:19] <elfy> :)
[21:19] <ali1234> how are you unmounting? with right click?
[21:19] <elfy> yea
[21:20] <ali1234> are you doing left click select then right click to open menu? or directly right clicking? i think that makes a difference?
[21:20] <ali1234> also i think click okay or cancel on each dialog might affect it too
[21:20] <elfy> right click on sidebar
[21:20] <ali1234> well yes
[21:20] <ali1234> but do you left click the item first to select it?
[21:21] <elfy> no - not left click select - direct right click on sidebar
[21:21] <ali1234> okay
[21:21] <elfy> and cancel dialogue
[21:21] <ali1234> that's what i am doing, and i always have to do it twice
[21:21] <ali1234> i cancel the failed ones and okay the okay ones
[21:21] <elfy> I've not had an okay one to okay
[21:22] <ali1234> oh? when i do the successful unmount i still get one of the dialogues
[21:24] <ali1234> https://www.youtube.com/watch?v=Lz1haetybhc
[21:24] <elfy> I wasn't - also this time it didn't creash
[21:31] <brainwash> finally some progress :)
[21:31] <elfy> ali1234: I don't get that second busy dialogue here after the open file is closed
[21:34] <elfy> ali1234: http://pastebin.com/sQ5L6wKK
[21:39] <ali1234> so the weird thing about this is that it's not slice/malloc mismatch, and it's not double free - because those should be caught by the various debug switches
[21:39] <ali1234> so really this can only be a pointer getting corrupted somehow, so it eventually tries to free something it's never seen before
[21:40] <ali1234> i guess the next step is valgrind with every possible test
[21:42] <elfy> well ... happy to help where I can, but you'll need to give me pointers with that
[21:42] <elfy> sounds like some Norse mythology ...
[21:44] <ali1234> te only thing valgrind showed up was this: http://paste.ubuntu.com/7401227/
[21:45] <ali1234> and it does involve "shortcuts" so it's a possibility
[21:48] <elfy> hi GridCube - I hammered out the xfce ones today
[21:49] <GridCube> hi elfy yes, i got an email from trello because i suscribed to the task
[21:50] <elfy> :)
[21:50] <elfy> but no mails about anything else?
[21:53] <GridCube> P: no because i did not suscribed to anything else
[21:54] <elfy> yep - just checking - knome appeared to be worried about that I think
[21:56] <sidi-valencia> would a virtual volume do it? elfy
[21:56] <elfy> not sure - I'm just following instructions :)
[21:57] <elfy> ali1234: I'm off now - if you think of anything you want me to try - tell forestpiskie and I'll read it with the first cuppa
[21:57] <elfy> night all
[21:58] <sidi-valencia> ali1234, that invalid write on a gobject_dispose...
[21:58] <sidi-valencia> which gobjects are related to volumes?
[21:58] <sidi-valencia> is it possible that smth gets freed straight away on a fail unmount?
[21:58] <sidi-valencia> i'd be looking for that personally :P
[21:58] <ali1234> i dunno, but that looks like something to do with icons... and the volumes do have icons... and they change when you mount/unmount
[21:58] <ali1234> yes, so maybe the icon gets freed too early on unmount
[21:59] <ali1234> although that would cause a double free, and valgrind would surely catch that
[21:59] <sidi-valencia> https://chipx86.github.io/gtkparasite/ would that debugger help?
[21:59] <sidi-valencia> Disclaimer: never used it :P
[22:00] <sidi-valencia> not necessarily a double free methinks
[22:00] <sidi-valencia> say you have a foo object for your volumes
[22:00] <sidi-valencia> pointing to bar and ter
[22:00] <sidi-valencia> and bar got a ref to ter
[22:00] <sidi-valencia> say foo frees ter but not bar when failing to unmount (which would be a bug obviously)
[22:00] <sidi-valencia> then later on disposing bar might cause bar to write stuff to ter such as a g_object_unref (ter)
[22:00] <sidi-valencia> but ter is already gone
[22:01] <sidi-valencia> not a free but definitely an invalid write
[22:01] <sidi-valencia> you never free a gobject directly normally
[22:07] <ali1234> nah, that's just like a dom explorer
[22:07] <ali1234> i've used it a lot
[22:08] <ali1234> hmm yeah
[22:08] <ali1234> this is pretty much all i can think of too
[22:08] <ali1234> going to dig into the code and find exactly where it crashes
[22:10] <ochosi> sounds good though
[22:10] <ochosi> that crash happens very frequently to me
[22:10] <ochosi> i think i can reproduce it 100% with my ipod
[22:10] <ochosi> unmounting is quasi inpossible with thunar
[22:10] <ochosi> impossible
[22:10] <ochosi> with gigolo unmounting works as it should
[22:12] <ochosi> unmounting/ejecting
[22:12] <ochosi> network shares are (as you stated correctly) also quite a sure shot for crashing thunar here
[22:21] <ochosi> Logan_: hey there! think you could sponsor this to get the SRU process going? https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/parole/gstreamer1.0-pulseaudio/+merge/216565
[22:21] <ochosi> it should be a fairly simple one, if you have any questions though, feel free to ping me or bluesabre
[23:25] <bluesabre> thanks ochosi


[15:43] <jml> james_w: ping
[16:23] <james_w> hi jml
[16:24] <jml> james_w: hi
[16:24] <jml> james_w: I thought I was late for our meeting.


[08:05] <jMCg> Hello happy people.
[08:06] <jMCg> I just discovered that the upstart cookbook uses some horrible anti-patterns in its examples
[08:06] <jMCg> for dir in `ls /var/lib/queues`
[08:11] <jMCg> Anyways, the question I'm here for actually, other than, how do I fix the examples in that cookbook and send you patches, is: Can I change setuid/setgid *per* instance?
[08:28] <jMCg> Use more quotes: http://apaste.info/12l8
[14:13] <toabctl> jodh, are you working on the file bridge? and if so, is there already some code?
[14:13] <toabctl> I also wanted to know if there is html documentation for libnih. would be nice to have this at developer.ubuntu.com
[14:14] <jodh> toabctl: yes, I am. I'll push some code somewhere soon. I forget who (xnox?), but someone @ UDS offered to auto-gen some dev docs using doxygen as NIH uses the KDE commenting-format.
[14:15] <xnox> jodh: s/KDE/gtk-doc/
[14:15] <jodh> xnox: close :)
[14:16] <xnox> toabctl: jodh: yeah I did generate gtk-doc locally for both, it doesn't look very nice (formatting errors), tried to clean up and integrated and it broke again.
[14:17] <toabctl> xnox, would be nice to autogenerate the doc with the package. so build-dep would be gtk-doc
[14:17] <jodh> toabctl: I appreciate this isn't to everyones tastes, but I've configured vim for ctags for nih+dbus so you can just CTRL+] to jump to the actual NIH code (and doc of course).
[14:18] <xnox> toabctl: jodh: filed as bug 1087269 subscribe if you are interested =)
[14:18] <xnox> toabctl: yeah, i know. But gtk-doc needs correct bootstrapping with autoconf first which I didn't quite do right the first time around. When it works, I will propose a merge ;-)
[14:19] <jodh> xnox: subscribed.
[14:20] <jodh> xnox: Keybuk still owns NIH upstream, but if you can put an NIH branch with doc changes somewhere we can work on a new release branch and see if it gets his blessing :)
[14:20] <jodh> I'm still waiting for STL man pages :)
[14:22] <toabctl> jodh, how do you want to implement user sessions? with a new upstart instance for every user? or only one upstart instance which handles all the stuff?
[14:22] <xnox> jodh: STL? stereolithography file format?
[14:22] <jodh> toabctl: it's all here: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
[14:23] <jodh> xnox: C++ standard template library :)
[14:23] <jodh> toabctl: but in short, 1 instance per user. Makes for a much cleaner design and avoids nasty DoS possibilities.
[14:23] <jodh> toabctl: make that 1 instance / user *session* :)
[14:24] <toabctl> jodh, something different is mentioned here: https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-upstart-session-requirements (see bottom of page)
[14:24] <toabctl> jodh, sometimes imho it's very confusing with alle the blueprints, wikis and mailinglists. I never know what's the right source
[14:25] <jodh> toabctl: that's the quantal blueprint, not the raring one.
[14:25] <toabctl> jodh, so half a year later all is different ? :-)
[14:25] <toabctl> jodh, some should at least mark the blueprint as outdated/invalid
[14:26] <toabctl> and point to the latest information for the topic
[14:26] <jodh> toabctl: it is marked "Implementation: Deferred".
[14:27] <jodh> toabctl: it's not that difficult - just go to https://blueprints.launchpad.net/ubuntu/$release (ie raring) and see what the community is working on.
[14:28] <toabctl> jodh, ok. and the blueprints from blueprints.launchpad.net/upstart ?
[14:32] <jodh> toabctl: first time I've seen that page :) Those bp's refer to "upstream Upstart projects" whereas we are driving changes via the Ubuntu project (even though they actually land in upstream Upstart first).
[14:38] <toabctl> :)
[21:50] <stgraber> slangasek: when you have a minute, I'd like an opinion on https://code.launchpad.net/~stgraber/ubuntu/raring/libnih/libnih-dbus-as-type/+merge/138582
[21:51] <stgraber> slangasek: it appears to work here, diffing upstart's generated code shows that it's only fixing the one variable I added, but I won't pretend to understand all the potential impact of that change ;)
[21:57] <slangasek> stgraber: hmm, I'm not familiar enough with this code myself to be a particularly good reviewer
[21:58] <slangasek> I can dive into it, but it'll take me a while.  Maybe it's better to have jodh review?
[21:58] <stgraber> slangasek: ok. I wasn't sure how much of libnih you knew about. I can wait till tomorrow for jodh to review.
[21:59] <stgraber> slangasek: at least I have a local build with that fix so I can now write tests for my dbus branch without having upstart die on me :)
[22:06] <stgraber> slangasek: spoke too soon, looks like I'll need more magic in nih, the generated code segfaults in upstart though the nih testsuite itself passed. I guess it's missing a test with an empty array...
[22:06] <slangasek> mmk :)
[22:25] <stgraber> right, so I managed to fix the generated code so that the upstart testsuite works, now to fix the generator to give me something that roughly matches my manually patched file :)


[05:54] <nithinkadakkal[m> How to install hp 1108 on Ubuntu 22.04
[14:20] <tomreyn> nithinkadakkal[m: if you have questions about Ubuntu, not UbuntuStudio, you'd better join channel #ubuntu on the Libera IRC network. I think you can also do so through matrix, but i'm not going to try to find out how.
[17:21] <Eickmeyer> tomreyn, nithinkadakkal[m: It's easy. Just join #ubuntu:libera.chat
[17:21] <Eickmeyer> tomreyn: Just appending :libera.chat gives them a clickable link.
[17:34] <tomreyn> Eickmeyer: thanks - let's see how long i can remember this. ;-)