[00:00]  * genii notes no leading slash before home
[00:01] <truelai> rsync -az "backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\/Apex.*" "root@10.1.1.74:/home/Users/amasse/AM Desktop"
[00:01] <truelai> rsync: change_dir "/backups/daily.0/MTL_fileSrv//backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\" failed: No such file or directory (2)
[00:02] <truelai> doesn't matter
[01:00] <sarnold> truelai: start with this:   ls -l  /backups/daily.0/MTL_fileSrv//backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\
[01:00] <sarnold> truelai: it'll probably fail
[01:00] <sarnold> truelai: start removing directory components from the end until you find where it succeeds
[01:00] <truelai> Thanks sarnold
[01:00] <truelai> having a new issue now
[01:00] <truelai> I want to prefix every line of a file with the following:
[01:01] <truelai> rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s
[01:01] <truelai> Any ideas?
[01:01] <truelai> I'm failing with both awk and sed
[01:03] <sarnold> awk '{print "hello " $_; }' /etc/passwd
[01:03] <sarnold> worked for me on a *simple* input file
[01:05] <truelai> awk '{print "rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s" $_; }' encrypted-files-full-path-escaped.txt out.txt
[01:05] <truelai> awk: cmd. line:1: {print "rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s" $_; }
[01:05] <truelai> awk: cmd. line:1:                                    ^ syntax error
[01:05] <sarnold> need more \  :)
[01:06] <truelai> for the period?
[01:06] <sarnold> the "ssh
[01:06] <truelai> can you show me the line?
[01:06] <truelai> awk '{print "rsync -az -e "ssh -i /root/\.ssh/id_ed25519" -s" $_; }' encrypted-files-full-path-escaped.txt out.txt
[01:06] <truelai> this does not work
[01:08] <sarnold> try: awk '{print "rsync -az -e \"ssh -i /root/.ssh/id_ed25519\" -s" $_; }' encrypted-files-full-path-escaped.txt
[01:08] <sarnold> I'm guessing you wanted the out.txt to contain this output -- if so, use > out.txt at the end
[01:08] <truelai> oh snap!!!
[01:08] <truelai> :-*
[01:08] <truelai> Thanks much, man!
[01:09] <sarnold> sed -ifoo  is also awesome
[01:09] <truelai> so are you
[01:09] <sarnold> that does an in-place edit on the file, creating a backup file with 'foo'
[01:09] <sarnold> <3 :) thanks
[01:09] <sarnold> I almost always use sed -i without a backup, but that's a bit dangerous unless it's something you *can't* mistype :)
[01:35] <rbasak> teward: on bug 1743592
[01:35] <ubottu> bug 1743592 in nginx (Debian) "NGINX fails to start/install/upgrade if IPv6 is completely disabled." [Unknown,New] https://launchpad.net/bugs/1743592
[01:35] <rbasak> I wasn't paying close attention, but I'm really surprised that you disabled IPv6 support by default in nginx in Focal. That does seem like a regression to me.
[01:36] <rbasak> slashd: ^
[01:36] <rbasak> IMHO, the default should be to focus on working on a default installation which would have IPv6 enabled.
[01:37] <rbasak> The real fix would be for nginx to support listening properly on all interfaces on port 80 whether they are 4 or 6 and regardless of whether one is disabled.
[01:39] <rbasak> My SRU opinion was just "don't change stable release behaviour". Sorry I didn't write up any suggestions for development release behaviour change at the time (AFAICT - I'm not contradicting myself, am I?)
[02:56] <teward> rbasak: we can revert that easy but the discussion was with others to disable it because that's what upstream has - feel free to revert that, or I will tomorrow
[02:56] <teward> this being said... that doesnt solve the ipv6 missing problem
[02:57] <teward> I was intending to revert it after thinking on it this evening
[02:57] <teward> I'll revert in the morning.  You want to summarize that we agreed collectively to not cater to v6-disabled cases?
[02:58] <teward> (I'm a little busy...)
[03:22] <rbasak> teward: I asked some colleagues their opinion. I appreciate you being so responsive, but let's make sure everyone is agreed to avoid reverting a revert :)
[03:23] <rbasak> Sure, I'm happy to summarize following discussion
[03:23] <rbasak> (also I'm technically out until Monday)
[03:51] <teward> rbasak: i think this was because there are some specialized deployments that disable v6 but... thats going to be a larger discussion.  Comment on the bug as well and indicate we are discussing more internally before a revert.  Todays been s*** to a high degree so I’m trying to NOT deal with stress at the moment
[03:51] <teward> Or rather, avoid some stress
[07:30] <lordievader> Good morning
[08:55] <ruben23> hi there guys anyone can help
[08:57] <ruben23> i got myself lockout on my ubuntu server i login as user ruben23 but when i do sudo it ask for password even i did not set any, problem i disable root access
[09:00] <lordievader> ruben23: What are you trying to do exactly?
[09:01] <ruben23>  lordievader: i got user ruben23 then i disable root login on my ssh server and this user i did not set a password, problem i cant do sudo with my user coz it ask for password
[09:02] <lordievader> How did you disable the root login?
[09:02] <lordievader> Were you able to use sudo before?
[09:02] <ruben23> so im pretty lockout.? i cant do anything.?  i disable it on sshd_config  ( permit root login - no
[09:03] <ruben23> lordievader: this is my first reboot to try it after setting up, problem its asking for password even i did not set
[09:04] <lordievader> You never used sudo before? It asks for your user's password.
[09:05] <ruben23> lordievader: yes
[09:08] <lordievader> ruben23: Does it work with your user password?
[09:15] <ruben23> lordievader: its working now, thanks a lot
=== Wryhder is now known as Lucas_Gray
=== V7 is now known as nopm
=== nopm is now known as [88]
=== [88] is now known as |88|
=== |88| is now known as V7
[16:07] <weedmic> How likely is plugging in a pci-e bluetooth card going to work?  my kids what to get bluetooth headsets for the living room
[16:07] <weedmic> is this something easy, or a pandora's box?
[16:07] <pragmaticenigma> Is this on a desktop or server?
[16:08] <weedmic> it is ubuntu 18.04 running on a dual linux 4u  convertible (tower).
[16:09] <pragmaticenigma> Other than bluetooth doesn't transmit well through walls... I'm not sure how robust the support is for the various chipsets on the market.
[16:09] <weedmic> if it's going to be a bother, is there a brand I should try to find - perhaps intel?
[16:09] <weedmic> ok, the only wall would be the case ?wrapper? as it is visible/open to air
[16:10] <weedmic> i guess it doesn't matter, i see the price is very very cheap - less than a snack/lunch - ty tho
[16:11] <pragmaticenigma> cheep may mean less support... but cheep means can't hurt to try
[16:11] <pragmaticenigma> just make sure it has an external antenna
[16:11] <weedmic> :D support - i've not had support since 1995 - i mention linux and they hang up
[16:12] <weedmic> good - i did not see an antenna in the advert - this is for bluetooth (not wifi).  looking at others
[16:12] <pragmaticenigma> well, I was referring to kernel supporting the chipset... but I think you knew that
[16:13] <pragmaticenigma> bluetooth through a metal case is going to be iffy... better if the card has at least some sort of co-axil port to hook an external antenna to. I'm not sure if all cards would come with the external antenna with the unit
[16:13] <weedmic> o oic, kernel support - still looking for one with antenna
[16:18] <pragmaticenigma> weedmic: I'd look for a "port" on the card, that lets you attach an antenna... Might be easier to find, and the card documentation should tell you what type of antenna connector and specs are supported
[16:22] <weedmic> ty
[16:37] <teward> rbasak: can you review the latest items?  Because I think trying to handle 'all cases' with customising postinst, etc. is a catch 22
[16:37] <teward> as is just going back to having v6 support out of the box
[16:37] <teward> need a second opinion
[16:37] <teward> preferably with a Canonical opinion/twist to it
[16:43] <sdeziel> teward: to add to possible solutions, using "listen [::]:80 default_server ipv6only=off;" alone seems to do the right thing no matter what is present, v4 only, v6 only or both
[16:44] <teward> sdeziel: i think we're still on a double edged sword.  Because if v6 is completely disabled I don't think that'll work
[16:44] <teward> that's the reason for the original 'bug' being filed
[16:44] <sdeziel> teward: maybe not a perfect test but I nuked all v6 on my test container and it worked
[16:44] <teward> i'm tempted to drop that delta from Debian and then go back to the original Listen lines and argue that the lack of v6 in a configuration is a nonstandard edge case that the 'defaults' cannot necessarily adapt to
[16:45] <teward> sdeziel: propose it on the bug then?
[16:45] <teward> the problem I see is
[16:45] <teward> if we keep catering things to these edge cases
[16:45] <teward> we're going to have such insane complexity it's not going to be a good thing
[16:45] <sdeziel> teward: yes, I'll add this to the bug
[16:46] <sdeziel> teward: I think that probing for available inet family is crazy ;)
[16:46] <sdeziel> I don't want dynamic variable configs ;)
[17:05] <rbasak> I know that there's a way in general on Linux for a single socket bind to listen on both and just dtrt.
[17:05] <rbasak> Maybe sdeziel's suggestion is exactly that.
[17:05] <sdeziel> it's what I'm trying to find, now trying other variations
[18:04] <teward> to be fair
[18:04] <teward> i'm OK with it displaying IPv6 addresses in there
[18:04] <teward> for logs
[18:04] <teward> as long as it has the addresses.  But that brings into question a larger question: do we really want v4 to show up as v6 translated in the logs?
[18:04] <teward> by default
[18:05] <teward> because that's what the change sdeziel proposed would make.
[18:22] <sdeziel> teward: yeah, I'm not too keen on having IPv4-mapped IPv6 (with the "::ffff:" prefix) but I never use the default vhost myself so I don't really care
[18:24] <teward> if the choice is between "Support no-v6 and no-v4 systems" and "ipv6 mapped v4" i'll choose the second, but the default fallback is "You guys are using non-standard configurations so just write your own configuration and deploy that"
[18:24] <teward> which would revert the changes I did to remove the v6 components and drop a delta
[18:35] <teward> given that FF comes up next week, I'd like to make a decision sooner than later, rbasak and sdeziel
[18:35] <teward> thoughts?
[18:46] <rbasak> teward: I think we should revert, but I think what to replace it with is perhaps still under discussion?
[18:46] <sdeziel> agreed on both counts
[18:46] <rbasak> But I think revert-and-do-nothing-else is still a better option than the current situation.
[18:46] <teward> i think leaving it without a replacement is satisfactory
[18:46] <teward> since not having ipv4 or not having ipv6 is not a 'normal' configuration
[18:47] <rbasak> I agree - the only question is if we can do any better
[18:47] <teward> at least, not what we would consider 'normal' for typical behavior of a system
[18:47] <teward> rbasak: I can think of a dozen things we can check - but that makes the complexity increase substantially
[18:47] <teward> this close to FF I don't want to introduce breakage, so I'm more inclined to revert and leave it alone, and then deal with *that* come 20.10 cycle
[18:47] <sdeziel> teward: having too clever postinst is dangerous IMHO
[18:47] <rbasak> What I'd like is a simple nginx configuration that will always listen on all available addresses on both 4 and 6 as available.
[18:47] <teward> sdeziel: *points at last statement*
[18:47] <teward> rbasak: that's only available if we use sdeziel's approach
[18:47] <rbasak> If that's not possible, we should file an upstream bug requesting that as a feature.
[18:48] <teward> there's no 'dynamic' listening that way
[18:48] <rbasak> And I'd be happy to leave it at that.
[18:48] <teward> well for the time being
[18:48] <rbasak> "listen [::]:80
[18:48] <rbasak>                 default_server ipv6only=off;"
[18:48] <rbasak> ^ that approach?
[18:48] <teward> yes, but that makes the logs all log IPv6 addresses ::ffff:10.1.2.3 as an example
[18:49] <teward> which adds a *different* problem into the mix
[18:49] <teward> logs no longer match expected format
[18:49] <teward> s
[18:49] <teward> DAMN YOU LAGGY INTERNET *throws a wrench at the work internet*
[18:49] <rbasak> That's not good either - especially as users would likely only find out too late.
[18:49] <rbasak> So in that case, I think revert and do nothing further for now is the best option.
[18:49] <teward> i agree
[18:49] <rbasak> And ask nginx to fix upstream, assuming that's possible with a listen on [::].
[18:50] <rbasak> (surely it is?)
[18:50] <teward> rbasak: you'd have to ask them :p
[18:50] <rbasak> Oh, I just saw the bug comment
[18:51] <sdeziel> the "::ffff:" can be confusing users and log parsers (those should be fixed though)
[18:57] <teward> rbasak: sdeziel: changes are revered in 1.17.8-0ubuntu2 which i'm uploading now
[18:57] <teward> i left the bug as 'Opinion' as we can discuss later.
[18:58] <sdeziel> sounds good to me, thanks teward
[18:58] <teward> (Opinion's what I use when the issue remains under discussion but no real solution has come from it yet to 'fix' the issue, or if it even is an issue)
[18:58] <rbasak> teward: thanks!
[18:59] <rbasak> teward: I think the bug is valid, but Wishlist. Perhaps no action without upstream support. But by default we should listen on both 4 and 6 as available, not fail if one is disabled, and log properly.
[19:00] <sarnold> I haven't been following closely but that sounds like a good outcome to me
[19:00] <rbasak> I think that's a reasonable position so Triaged is fine - awaiting someone to implement that upstream as required, or find some other acceptable solution.
[19:01] <teward> rbasak: i don't disagree (If you want to set it as Wishlist you can, but right now the requested functionality doesn't track with the goal for this cycle which is why I chose Opinion.  That said, I've got my own headaches with migrating mail between IP ranges right now, so I can't send that email at the moment to the mailing lists - any chance you can email in to nginx-devel@nginx.org for that discussion?
[19:01] <teward> since moving IP ranges also means complete mail system reconfiguratiosn >.<
[19:01] <sdeziel> In my opinion, upstream already supports what you described rbasak. I think that ipv4-mapped IPv6 should be considered valid to put in logs, even if it may be confusing to some
[19:01] <teward> i don't disagree with sdeziel
[19:01] <teward> but lets make that logging change a 20.10 'target'.
[19:01] <teward> rather than for 20.04
[19:02] <teward> this close to FF I don't want to break logging parsing