| nacc | rbasak: the former, yes | 00:11 |
|---|---|---|
| nacc | rbasak: i think i'd need to do some refactoring, but actually, if you're ok with me pulling the parsing to its own module, i think it will make the changes pretty straightforward | 00:11 |
| nacc | rbasak: basically, the issue right now is you need a repo object to parse under | 00:11 |
| rbasak | nacc: making it more module and testable makes sense. I think it's fine to be in its own module then. | 00:12 |
| rbasak | nacc: or at least outside the class but in the same module? | 00:12 |
| nacc | rbasak: but I think i can abstract all of that out to gitubuntu/changelog.py and just put tests there (before your series), then your series is just changing that class | 00:12 |
| nacc | rbasak: yeah, maybe the latter is sufficient | 00:12 |
| nacc | rbasak: just out of GitUbuntuRepository | 00:12 |
| rbasak | nacc: in general I imagine we'll be moving plenty of stuff outside classes in order to make them more easily testable. | 00:12 |
| nacc | rbasak: sounds like a plan, thanks! i'll work on that tmrw | 00:13 |
| nacc | rbasak: ack | 00:13 |
| nacc | rbasak: basically, first commit will create a Changelog class (without using debian's changelog class) and just move our functionality into there, ideally with no changes -- then yours comes in and reworks that class | 00:14 |
| lordievader | Good morning | 06:14 |
| === JanC is now known as Guest77859 | ||
| === JanC_ is now known as JanC | ||
| Genk1 | Hello All I have an annoying problem after I replaced my current Thawte certificate with the new letsencrypt free ssl certificate | 10:34 |
| Genk1 | in fact https://www.ssllabs.com/ still show me that there are 2 kinds of certificates a valid one which from letsecnrypt and the expired one from Thawte | 10:35 |
| Genk1 | How can I fix this please ? | 10:35 |
| tomreyn | Genk1more details needed | 10:35 |
| tomreyn | ssllabs.com server test will in no situation report two sercer certificates in use in a single report | 10:36 |
| Genk1 | tomreyn: I am running an ubuntu server 16.04 with apache, I have verified that there are only one vhost | 10:36 |
| Genk1 | tomreyn: in fact he showed me two certificates | 10:37 |
| tomreyn | that is unless you have those setrver certificates in the ssl trust chain | 10:37 |
| tomreyn | post the output on pastebin, replace anything you do not feel comfortable sharing | 10:38 |
| tomreyn | you can produce plain text output using https://github.com/ssllabs/ssllabs-scan | 10:39 |
| Genk1 | tomreyn: OK | 10:39 |
| Genk1 | tomreyn: Ok thanks | 10:39 |
| Genk1 | but normally those kind of issues is related to the webserver right ? or maybe it's a caching issue ? | 10:40 |
| tomreyn | yes it's a configuration issue, not a caching issue | 10:41 |
| Genk1 | tomreyn: but I only have two ssl directive pointing to letsecrypt path file | 10:41 |
| Genk1 | how it can be possible, I have only vhost and it's in front of me ? | 10:42 |
| Genk1 | I don't see any information about thawte | 10:42 |
| tomreyn | Genk1: i could not tell, and do not know your server configuration. run "sudo apache2ctl -t -D DUMP_VHOSTS" to check what you have. | 10:44 |
| Genk1 | I have done this before don't worry I know what I am saying :) | 10:45 |
| Genk1 | tomreyn: I am sure the issue is not on the server side | 10:45 |
| Genk1 | because some clients can access the new certificate and some others cannot | 10:46 |
| tomreyn | sudo rgrep -Ei 'SSL(CA)?Certificate' /etc/apache2/ | 10:46 |
| Genk1 | it's clearly a caching issue | 10:46 |
| tomreyn | do you have a proxy in front then? | 10:46 |
| nav- | indeed, sounds like a caching issue | 10:47 |
| nav- | for the ones it's not working, try it in an incognito tab | 10:47 |
| tomreyn | ssl content should never be cached, this would be a configuration issue | 10:47 |
| Genk1 | tomreyn: it shows this | 10:48 |
| Genk1 | SSLCertificateFile/etc/letsencrypt/live/*/fullchain.pem | 10:48 |
| Genk1 | SSLCertificateKeyFile /etc/letsencrypt/live/*/privkey.pem | 10:48 |
| Genk1 | the other directives are commented | 10:48 |
| Genk1 | nav-: | 10:48 |
| tomreyn | <tomreyn> do you have a proxy in front then? | 10:48 |
| Genk1 | ok thanks | 10:48 |
| Genk1 | tomreyn: no no it's a simple webserver that I have hosted myself in OVH | 10:49 |
| Genk1 | tomreyn: I did an installation from scratch | 10:49 |
| tomreyn | okay so it can only be browser caching then indeed. | 10:50 |
| tomreyn | i always thought it was wrong they introduced that | 10:50 |
| Genk1 | tomreyn: voila | 10:51 |
| tomreyn | or it's client side proxies, which would be even worse | 10:51 |
| necrophcodr | I'm trying to remove old 3.13 kernels and stuff on my 14.04 installation, however aptitude keeps pulling them back | 10:59 |
| necrophcodr | Is there any way I can avoid this? | 10:59 |
| lordievader | Check out the reason why aptitude is pulling them back in. | 11:00 |
| lordievader | Could you provide some console output? Of removing the (old) kernel and updating, or something. | 11:01 |
| necrophcodr | lordievader: i've removed all the packages | 11:01 |
| necrophcodr | `aptitude remove -yq $(aptitude search --disable-columns '~i^linux-' -F '%p'|awk '/3.(11|13|16|19).0/') >/dev/null` | 11:01 |
| necrophcodr | Afterwards, running `aptitude install` pulls the header files back in | 11:02 |
| necrophcodr | I'm not sure how to check why it's pulling them back in, i wouldn't ask here otherwise. | 11:02 |
| lordievader | Could you show the 'apt-get update' output after removing them? | 11:02 |
| necrophcodr | update? you don't mean upgrade? | 11:03 |
| lordievader | Erm, yes. 'apt-get upgrade'* | 11:03 |
| necrophcodr | http://paste.ubuntu.com/25239340/ | 11:04 |
| necrophcodr | apt-get isn't as strict as aptitude though. | 11:04 |
| lordievader | So it seems, apt tells that it doesn't see a reason to keep those packages around. | 11:04 |
| necrophcodr | those are different packages | 11:05 |
| necrophcodr | not the 3.13 ones | 11:05 |
| necrophcodr | it doesn't pull in new packages. but we're using aptitude. | 11:05 |
| lordievader | What is the output of 'apt-cache rdepends linux-header-3.13.0-X' (correct the version) | 11:07 |
| necrophcodr | lordievader: i did that, and some more: | 11:10 |
| necrophcodr | http://paste.ubuntu.com/25239357/ | 11:10 |
| necrophcodr | but i think the issue might be that linux-libc-dev is of version 3.13 | 11:10 |
| necrophcodr | hmm..no, there doesn't seem to be a direct corelation | 11:11 |
| lordievader | Could be, but I would expect libc-dev to have a dependency on a header package. Though it could depend on the meta package of the linux-headers. | 11:12 |
| necrophcodr | it depends on linux-kernel-headers | 11:12 |
| necrophcodr | or rather, it provides that | 11:12 |
| lordievader | What happens when those headers are removed along with the rdepends? Just to see if apt handles this differently from aptitude, does apt also want to reinstall them? | 11:13 |
| necrophcodr | i don't have them installed at all | 11:13 |
| necrophcodr | not the rdepends either | 11:13 |
| necrophcodr | i removed them as stated earlier, and apt doesn't want to install them | 11:13 |
| necrophcodr | aptitude does, but it handles things differently. | 11:14 |
| lordievader | But aptitude does? | 11:14 |
| necrophcodr | yes | 11:14 |
| lordievader | Strange. | 11:15 |
| lordievader | There is not some package among the install list which could pull in the rest as a dependency? | 11:15 |
| necrophcodr | I'm not sure, how do I verify this? | 11:16 |
| lordievader | Well, I suppose you get a confirmation when running 'aptitude install' (I must admit, I rarely use aptitude). | 11:16 |
| necrophcodr | oh that | 11:17 |
| necrophcodr | no, not as far as i can tell | 11:17 |
| necrophcodr | no packages are scheduled for upgrading, and there's a few packages being removed. | 11:17 |
| necrophcodr | i can deal with using apt-get for the rest of time, but i'd prefer to use aptitude, as i've heard it should handle dependencies and such more strictly. | 11:18 |
| lordievader | I thought I read a document somewhere where they recommended Debian users to use apt-get over aptitude. | 11:18 |
| necrophcodr | lordievader: yep, that was especially for upgrading, since it didn't care that not everything was super in order | 11:19 |
| lordievader | I see. Still, stricter rules should not install packages which are not needed, I'd say. | 11:20 |
| lordievader | In the man page I read of a 'why/why-not' command, it says 'explains the reason that a particular package should or cannot be installed on the system'. | 11:21 |
| lordievader | That may explain why it wants to install header files. | 11:21 |
| necrophcodr | lordievader: it doesn't really expain anything unfortunately :/ | 11:43 |
| necrophcodr | http://paste.ubuntu.com/25239552/ | 11:44 |
| necrophcodr | The thing is that aptitude doesn't automatically install suggested packages. | 11:44 |
| lordievader | Hmm, none of those suggested packages are installed? | 12:02 |
| necrophcodr | lordievader: nope, not a single one | 12:22 |
| lordievader | Then I really don't understand why aptitude wants to install it -.- | 12:22 |
| necrophcodr | lordievader: that's my predicament. i don't understand it either. | 12:27 |
| lordievader | I don't really want to say 'use apt-get' but that seems about the sanest option right now. | 12:28 |
| necrophcodr | lordievader: i'll evaluate further options, but you might be right | 12:47 |
| necrophcodr | thanks for your help though! | 12:48 |
| lordievader | No problem ;) | 12:49 |
| genk1 | tomreyn: how to deal with such problems | 13:15 |
| genk1 | https://www.ssllabs.com/ssltest/analyze.html?d=www.myniu.fr&latest | 13:16 |
| genk1 | 2 certificates in the same time | 13:16 |
| mdeslaur | nacc: hi! I'm looking at php security updates....is there a round of 7.0 updates being worked on for xenial/zesty? | 13:24 |
| ahasenack | hi, a packaging question | 13:34 |
| ahasenack | if I have a package that installs a script in /etc/update-motd.d/ | 13:35 |
| ahasenack | because it's in /etc, it's considered configuration | 13:35 |
| ahasenack | and not removed via "apt remove", just "apt purge" | 13:35 |
| ahasenack | but it's a script, not a config file, and it's run on login. It might need the package installed in order to work properly | 13:35 |
| ahasenack | how is this usually sorted? | 13:35 |
| genk1 | tomreyn: I fixed the issue | 13:55 |
| genk1 | the problem was related to apache, some process child was still running and have the old configuration | 13:56 |
| genk1 | service apache2 restart and even service apache2 stop didn't stop apache really | 13:56 |
| genk1 | I needed to do a killall | 13:57 |
| genk1 | after that everything was working just fine | 13:57 |
| genk1 | thank you all | 13:57 |
| sdeziel | ahasenack: update-notifier-common drops snippets in /etc/update-motd.d where they do "[ -x /usr/lib/... ] && exec /usr/lib/..." and presumably removing the package removes the /usr/lib/... file | 14:05 |
| ahasenack | so the file in /etc remains, but does nothing | 14:06 |
| ahasenack | this one calls out to a snap, I'm not sure I should hardcode the snap bin path | 14:06 |
| ahasenack | with the -x check | 14:07 |
| ahasenack | but I can find another way | 14:07 |
| sdeziel | ahasenack: that would be my assumption but the update-notifier-common package was the one example I could fine | 14:07 |
| ahasenack | ok, thanks | 14:07 |
| === ogra_ is now known as ogra | ||
| === drab_ is now known as drab | ||
| nacc | mdeslaur: i noticed that debian had moved up, I can do that early next week (bump to 7.0.20) | 15:12 |
| mdeslaur | hrm, I need 7.0.22 | 15:13 |
| nacc | mdeslaur: let me check debian again | 15:13 |
| nacc | mdeslaur: oh nm! 7.0.22 indeed | 15:13 |
| nacc | mdeslaur: should be a straightforward update on my end. Do you want me to send the stuff your way so it goes security -> updates? | 15:14 |
| mdeslaur | yeah, stick it somewhere and I'll build it as a security update | 15:14 |
| nacc | mdeslaur: and just so i actually remember this time, you want it in the security pocket "before" the updates pocket? Or is that less relevant? (I recall you having to do two pocket copies for a prior upload) | 15:15 |
| mdeslaur | we have two options: 1- we sru it into -updates and then I rebuild it in -security a week later, or 2- I build it as a security update, and release it to -security | 15:16 |
| mdeslaur | if the update is straightforward without any big packaging changes, I can push it as a security update directly | 15:16 |
| mdeslaur | ie: no dependency changes, etc. | 15:17 |
| mdeslaur | nacc: show me the package once you've worked on it and I'll see if it can directly be released as a security update | 15:17 |
| nacc | mdeslaur: yeah, i expect no packaging changes, based upon prior uploads, but i'll let you know | 15:18 |
| mdeslaur | ok, thanks | 15:18 |
| === smoser` is now known as smoser | ||
| rbasak | nacc: style file pushed. | 16:58 |
| rbasak | I added some more items while I was thinking of them. Feel free to dispute :) | 16:58 |
| nacc | rbasak: thanks! | 17:02 |
| === JanC_ is now known as JanC | ||
| oerheks | gabrielc did this happen *after* you got chrome 60 ? | 18:34 |
| oerheks | odd, that new signingkey is not announced .. | 18:34 |
| nacc | rbasak: seeing a very strange failure with src:pacemaker (a --no-fetch re-import to test my changes). One specific version of pacemaker orig is showing up with hearbeat_(version).orig.tar.gz in pristine-tar instead of pacemaker_(version).orig.tar.gz. Running `gbp import-orig` manually on the same file (based upon the logs from the importer), it creates the pacemaker orig tarball correctly. I believe | 20:51 |
| nacc | `gbp` only uses the tarball name to determine the srcpkg and I don't see anywhere that would make it see heartbeat... | 20:51 |
| rbasak | nacc: file a bug I guess? I don't see right now what's going on. | 21:16 |
| nacc | rbasak: i added a bunch of debugging | 21:18 |
| nacc | rbasak: and i see what's happening but not sure why | 21:18 |
| nacc | rbasak: looks to be a gbp bug :) | 21:18 |
| nacc | gbp:info: Source package is heartbeat | 21:19 |
| nacc | rbasak: bug filed | 21:19 |
| nacc | rbasak: for the importer that is, i'll communicate with upstream once i undersatnd why :) | 21:20 |
| cliluw | Can I automatically give a user a root shell when they SSH in so that they don't have to preprend "sudo" before their privileged commands or have to run "sudo -s"? | 21:50 |
| nacc | cliluw: i don't think you would generally want to do that | 22:13 |
| sarnold | if you want the user to be root you could set the uid in shadow and passwd to 0, and set the home dir to match | 22:13 |
| cliluw | nacc: Generally, that's correct. In this case, I do want to do this - this is for an automated script. | 22:13 |
| nacc | cliluw: note, though, your question isn't exactly coherent | 22:17 |
| Poster | if it's automated, you can set "PermitRootLogin without-password" in your /etc/ssh/sshd_config then use SSH keys to bring the user in | 22:18 |
| nacc | cliluw: 'giving a user a root shell' does not only mean "that they don't have to prepend "sudo" before their privileged commands"... | 22:18 |
| nacc | cliluw: it means all commands are privileged commands :) | 22:18 |
| Poster | it would be better to use sudo and limit what commands can be used | 22:18 |
| sarnold | or set authorized_keys restrictions on what can be executed by the program, and optionally enforce that with apparmor and pam_apparmor .. | 22:19 |
| rbasak | IMHO, if the manner in which ssh is used means that people are using unrestricted sudo all the time in practice, then it's fine to log in directly as root. This is against the accepted wisdom though. | 22:19 |
| rbasak | It's only of value to create independent users for individual admins if sudo is restricted and/or actual auditing really happens of what they do. | 22:20 |
| rbasak | Otherwise the per-admin user is just a hurdle that provides no actual security benefit. | 22:21 |
| nacc | right, I think in this case, use ssh keys, allow ssh as root with specific keys, is the best choice | 22:22 |
| nacc | (presuming cliluw's description is accurate) | 22:22 |
| drab | cliluw: cleanest, and simplest/quick) (which for me has been at times very important) solution is to PermitRootLogin without-password, set up a passwordless ssh key on the client and use the "command" to launch a simple bash script that filters what's allowed (and potentially logs things) | 22:23 |
| drab | security is only useful when measured against realistic threats and targeted assets | 22:23 |
| nacc | heh | 22:24 |
| nacc | drab: +1 | 22:24 |
| drab | otherwise it's just stuff that sounds nice to the hears and looks good in a presentation | 22:24 |
| rbasak | Restricting to a simple bash script that filters and logs is a good idea, but be careful about implementation. It's quite easy to leave other channels open, making it pointless if your threat model includes a malicious (or compromised) admin. | 22:25 |
| drab | if I could only get back all the time I wasted on "best practices in a vacuum" I'd enjoy a vacation for the rest of my life :P | 22:25 |
| drab | rbasak: agreed | 22:25 |
| cliluw | nacc: Allowing root login is an option but not ideal. I would prefer that the actions of the script show up as a non-root user for better auditing. | 22:28 |
| nacc | cliluw: is the user logging in with a password? or ssh key? | 22:28 |
| cliluw | nacc: Only SSH key, no password | 22:28 |
| nacc | cliluw: if the latter, you can give them passwordless sudo, since it seems like your model is trusting that specific user (and their key)? | 22:28 |
| nacc | cliluw: again, not recommended, but if you want it for auditing, that would work | 22:29 |
| nacc | cliluw: they'd need to type sudo, but they wouldn't be prompted for a password, at least | 22:29 |
| drab | or you can use the command and wrapper and prepend sudo to all of them after confirming the cmd is allowed | 22:29 |
| nacc | cliluw: otherwise, i think, you'd need to add the user to the appropriate group or do what sarnold suggested | 22:29 |
| nacc | drab: ah true, yeah, that'd work | 22:29 |
| cliluw | drab: Seems a bit tricky to write a wrapper script that will be able to filter down to only the commands I want to run since Bash is such a syntactically complex language. | 22:34 |
| drab | cliluw: it depends what you're doing, for CI type of stuff ime it was very simple, sometimes a straight string match with a simple check on special characters like ; | 22:35 |
| drab | but like I said, I'm not you and I don't have your exact problems, so I don't know | 22:36 |
| drab | I've really come to believe in specificity and constraints, we all make tradeoffs all the time, whichever is best for you I don't know | 22:36 |
| nacc | rbasak: what did we decide to do about MPs that already were sponsored? https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/326073 | 22:37 |
| cliluw | drab, nacc: Thanks for your advice. I'll probably go with passwordless sudo option. It sucks to have to prepend "sudo" to every command but it's not the end of the world, I suppose. | 22:38 |
| drab | cliluw: if you do that you might as well have a "blank" wrapped that prepend sudo | 22:41 |
| drab | nothing to lose | 22:41 |
| drab | wrapper* | 22:41 |
| drab | at least it takes the suckiness out of it for you and it requires no additional investment to setup other than one line in the authorized_key file and one line in the bash script | 22:42 |
| drab | well, two with the header :) | 22:42 |
| rbasak | nacc: I've been pushing upload tags for those regardless, since they can be picked up by 1) any developer who is doing archeology or another merge, even if it wasn't incorporated into the commit graph by the importer; and b) our expected re-imports before we declare commit graph stability | 22:45 |
| ikla | how do you install on an EFI partition | 23:48 |
| ikla | the installer doesn't support it? | 23:48 |
| drab | ikla: the installer most definitely supports it | 23:51 |
| ikla | 16.04.2 ? | 23:51 |
| drab | yes | 23:51 |
| ikla | there is no option for EFI partition type | 23:51 |
| ikla | in manual mode | 23:51 |
| drab | it goes into efi install if it boots as efi | 23:51 |
| drab | are you positive the installed booted from an efi device/as efi? | 23:51 |
| drab | iirc there's no way to manually specify "install in efi mode" | 23:51 |
| drab | it depends upon boot time | 23:52 |
| ikla | no | 23:52 |
| ikla | you can create partitions manually | 23:52 |
| ikla | bios boot | 23:52 |
| ikla | then efi part | 23:52 |
| ikla | then all the rest | 23:52 |
| ikla | shouldn't matter if you booted from efi or legacy | 23:52 |
| ikla | boards support dual mode and could possibly boot non-efi but still have support | 23:52 |
| ikla | can I pass a kernel parameter to force the installer into efi? | 23:53 |
| ikla | cause it has no option in manual mode which is b.s. | 23:53 |
| drab | ok, maye you're right, all I know is what I experienced, efi installs worked when I booted in efi mode, but I never tried to create an efi install when booting in bios mode | 23:53 |
| ikla | even tried creating the partitions with fdisk | 23:53 |
| drab | I don't recall of any specific option to the kernel, no | 23:54 |
| ikla | set the correct partition types and the install in manual mode doesn't know how to handle them | 23:54 |
| drab | but I don't do a lot of efi, only needed it once to boot from a nvme partition | 23:54 |
| ikla | yeah - I only have an NVMe device | 23:54 |
| ikla | in this system | 23:55 |
| ikla | :) | 23:55 |
| drab | so yeah, in my case all I ddi was to create a usb install key, press f9 at boot and selected the key under the UEFI tree instead of Legacy tree | 23:57 |
| drab | and then in manual mode I could create the efi partition and all | 23:57 |
| drab | that's the best/most I can offer from the little I knwo about it | 23:57 |
| ikla | I'll try that | 23:58 |
| drab | mind you, my plan ultimately failed... but that was a bios problem | 23:58 |
| drab | even after correctly installing to the nvme device I could not subsequently boto from it | 23:59 |
| drab | in case this info is of any use to you... I spent 4 days going back and forth with SM support about nvme bios to conclude this wasn't possible on X9s | 23:59 |
| sarnold | aww | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!