text:
[bug] Lines 210 to 222 may cause an install abort on Ubuntu, git bash, & WSL when using auto installer

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
0.4.6
wagmi Version
version installed with pnpm create @rainbow-me/rainbowkit@latest
Current Behavior
Lines 210 to 222 cause an install abort on Ubuntu & WSL when using:
npm init @rainbow-me/rainbowkit@latest
# or
yarn create @rainbow-me/rainbowkit@latest
# or
pnpm create @rainbow-me/rainbowkit@latest

Therefore, removed highly opinionated git init and other actions on lines 210 to 222.
At least for git on Linux, WSL, and git bash on windows, you'll need to commit to master before attempting to rename branch to main
Otherwise it will cause an error because there is no reference to HEAD to any branch if nothing as been committed yet.
And, you can try also replicate this by manually creating repo running on Ubuntu or WSL. Try to rename the default branch without committing and you'll get a HEAD not found ref error.
Rainbow give this error:
  shortMessage: 'Command failed with exit code 128: git branch -m main',
  command: 'git branch -m main',
  escapedCommand: 'git branch -m main',
  exitCode: 128,
  signal: undefined,
  signalDescription: undefined,
  stdout: '',

Which is because of the head issue and renaming a branch with 0 commits
Expected Behavior
It may or may not be good idea to automatically perform repo commits on end user's local system. However, Next.js does it and it works great!
Steps To Reproduce
And, you can try also replicate this by manually creating repo running on Ubuntu, git bash for windows, or WSL. Try to rename without committing and you'll get a HEAD not found ref error.
mkdir test && cd test && git init && git branch -m hotdog
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
On WSL DO:  mkdir test && cd test && git init && git branch -m main
Anything else?
Pull request to remove those lines:
https://github.com/rainbow-me/rainbowkit/pull/650

This issue should be fixed in create-rainbowkit v0.1.2 as we no longer forcibly rename the branch.

This issue should be fixed in create-rainbowkit v0.1.2 as we no longer forcibly rename the branch.

Thanks @markdalgleish .  Will reinstall and test it out. Appreciate the follow-up!

@markdalgleish confirming the issues was fixed.

authors: codesport markdalgleish

repo: rainbow-me/rainbowkit


text:
🛑 RiotSkin4CN-Download is down

In ccb446d, RiotSkin4CN-Download (https://s-cd-4307-general.oss.dogecdn.com/riotskin4cn/live.json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RiotSkin4CN-Download is back up in 2f73731.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Is this package alive and supported

Wanted to see if this package is still maintained and supported, I see open issues and 7 pull request. Is it just better to use NPM packages?

it's still alive - depending on the direction Meteor is taking npm might be the place in the future + I'm guessing mongo db and ddp will deprecate in favor of graphql? making this package obsolete or candidate for a complete rewrite...
React native also got push right? (anything to avoid cordova plugins)

Hi @raix , What is this project future? Do you have any idea about release it as a npm package or add new features to it?

@cyclops24 I don't have any plans for moving it to npm. I think / hope that the future of this package will be deprecation - the cordova and react-native plugins are getting better so theres most likely no need for unifying the api any more. Sending notifications from the server is fairly trivial to implement or use a service for sending messages so you might want that when scaling is needed.
I'm not using the push package my self anymore and not using Meteor either - but if there are pr's I'll review and release.

Thank @raix for your attention,
Which cordova or react-native plugins you suggest as a raix:push alternative?
Send to Meteor userId is a very useful feature in your package which package now has this feature?

@raix is this package not working in meteor 1.8.1?
I'm saying it because after adding this package, meteor start giving me error.

@akatrodiya It's working, please follow the steps provided.
Alternatively you can go through this https://github.com/raix/push/issues/361#issuecomment-463692629

repo: raix/push

license: mit

license_source: bigquery


text:
Malayalam support added and multiple correction in 4 existing Indian languages

Adds Malayalam language support
Multiple correct in 4 additional language - Hindi, Marathi, Telugu, Kannada

Added few missing quotes etc.

source: gharchive/pull-request


text:
Themes still use deprecated background_opacity field.

Describe the bug
Any terminal instances I open have a big yellow warning message at the bottom saying
Config warning: background_opacity is deprecated; use window.opacity instead

I could go to my ~/.config/alacritty/alacritty.yml and manually change the field, but it will revert everytime I run alacritty-themes to switch to another theme.
To Reproduce

Installation
yay -s alacritty-themes

Run alacritty-themes

Operative System:
Arch, Linux 5.15.19-1-lts
An example of a theme .yml file that alacritty-themes writes to ~/config/alacritty/alacritty.yml
colors:
  name: Atelierheath (dark)
  author: Chris Kempson
  primary:
    background: "#1b181b"
    foreground: "#ab9bab"
  cursor:
    text: "#1b181b"
    cursor: "#ab9bab"
  normal:
    black: "#1b181b"
    red: "#ca402b"
    green: "#379a37"
    yellow: "#bb8a35"
    blue: "#516aec"
    magenta: "#7b59c0"
    cyan: "#159393"
    white: "#ab9bab"
  bright:
    black: "#776977"
    red: "#ca402b"
    green: "#379a37"
    yellow: "#bb8a35"
    blue: "#516aec"
    magenta: "#7b59c0"
    cyan: "#159393"
    white: "#f7f3f7"

background_opacity: 0.8
theme: Atelierheath.dark
me: Default.light

Screenshots
Add screenshots to help explain your problem.

Hi @michaelmoreno, Thank you for opening this issue, you just need to change from background_opacity to the opacity attribute.
colors:
  name: Atelierheath (dark)
  author: Chris Kempson
  primary:
    background: "#1b181b"
    foreground: "#ab9bab"
  cursor:
    text: "#1b181b"
    cursor: "#ab9bab"
  normal:
    black: "#1b181b"
    red: "#ca402b"
    green: "#379a37"
    yellow: "#bb8a35"
    blue: "#516aec"
    magenta: "#7b59c0"
    cyan: "#159393"
    white: "#ab9bab"
  bright:
    black: "#776977"
    red: "#ca402b"
    green: "#379a37"
    yellow: "#bb8a35"
    blue: "#516aec"
    magenta: "#7b59c0"
    cyan: "#159393"
    white: "#f7f3f7"

opacity: 0.8
theme: Atelierheath.dark
me: Default.light

Update alacritty template https://github.com/rajasegar/alacritty-themes/pull/99

authors: JuanVqz michaelmoreno

repo: rajasegar/alacritty-themes


text:
Support async server-side init script

If I understand the docs correctly, the server should be initialized in entry-hattip.ts. Is there a way to run async initialization code? The default export must be a HattipHandler. Options that come to mind:

also accept a Promise<HattipHandler> as default export
also accept an async function as default export that returns Promise<HattipHandler>
extend HattipHandler with a hook for async server-side initialization

Thanks

The problem is, server initialization only makes sense in long running servers: Serverless and edge functions don't really have the concept because there's no running server outside of the request/response cycle. Having an initialization hook may give the user the wrong impression that it will only run once even though it will run on (almost) every request on serverless and edge environments.
Having said that, you ca use top-level await for async initialization. On environments that don't support top level await, you can use the deferred promise pattern:
import { createRequestHandler } from "rakkasjs";

const initializationPromise = doSomeAsyncInitialization();

export default createRequestHandler({
  middleware: {
    beforePages: [
      async () => {
        // BeforePages middlewares always run first
        // so we'll ensure that initialization is complete
        // before anything else happens
        await initializationPromise;
      }
    ],
  },
});

Oh my. Of couse. Thanks for bringing that up again. I had totally forgotten that this is all serverless. Need to get rid of these old patterns in my mind.

repo: rakkasjs/rakkasjs


text:
Cannot ping a Bedrock Server

I've tried both Minecraft related MagicMirror2 modules and neither can ping my in-house Minecraft Bedrock server.  Do you have any idea on why this would be the case?

Many!  But first, thanks for trying out my MM Minecraft plugin.
Let's start with the software on the box and work on anything on your MM box that might be getting in the way.
Can you ping from the MM box to the Minecraft box?  If that works, it eliminates basic networking problems, but if it fails, it doesn't necessarily mean much...firewalls can block ICMP like ping.
Give "traceroute" a try if you know that.  If there is an intermediate router between MM and Minecraft it'll let us know how far a packet can get.
If these fail, there could be a firewall or something else blocking traffic from leaving the MM box, however unlikely that might be.
If you have "nc" installed on the MM box, or want to install it, that's another way to check network connectivity.  Something like echo "hithere" | nc 1.2.3.4 567 where 1.2.3.4 is the Minecraft box and 567 is the port the Minecraft software is listening on.  That'll use plain TCP to connect.
Can you describe your network setup too?  That can help iron out something strange.  I.e., is your MM and Minecraft box on the same network segment?  Separated by a router or switch?
Is there a specific error message you're seeing in the MM logs that could shed some light on things?  If MM-MinecraftStatus can't reach the Minecraft server, it prints an error message in the browser's console.  If you're not familiar with that, we can run MM "serveronly" and connect from a regular FireFox or Chrome browser and look at the console logs for something specific.
I'm sorry, but I don't know your general level of network savvy and if you've worked with a browser console before.  Please write back and let me know what from above sounds good, and what you're unfamiliar with.  I'll explain more in detail to get things moving!
Don't worry, we'll figure this out.

My day job has been in Operations so taking care of minor networking issues
won't scare me off.
Network Specs
Unifi Hardware: USG, Cloud Key1, and three switches.
vlans are in place.  MagicMirror (Hardware is a Raspberry Pi 4) is on the
primary LAN network.  Minecraft Bedrock Server is running off an older PC
with a fresh copy of Ubuntu Desktop installed.  This device is running on
my kid vlan.  Already using your MMM-MinecraftStatus to ping a Java Based
Minecraft Server (running off a another Raspberry Pi 4).  This Java Server
PI is on the same vlan as the Bedrock Ubuntu server.  MMM-MinecraftStatus
can see and report back on the Java Server without issue.  I do have a
MMM-MinecraftStatus2 module created (I believe correctly) to report back on
the Ubuntu Bedrock Servers status.
Traceroute Results:
From Office PC to Server
C:\Users\RJDaPirate>tracert 192.168.50.23
Tracing route to 192.168.50.23 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms  192.168.1.1
2    <1 ms    <1 ms    <1 ms  192.168.50.23
Trace complete.
From Raspberry Pi 4 currently hosting MagicMirror2
pi@raspberrypi:~ $ sudo traceroute 192.168.50.23
traceroute to 192.168.50.23 (192.168.50.23), 30 hops max, 60 byte packets
1  192.168.1.1 (192.168.1.1)  0.346 ms  0.441 ms  0.582 ms
2  192.168.50.23 (192.168.50.23)  5.243 ms  5.351 ms  5.429 ms
Tried my best but I cannot figure out how to send the echo "hithere".
Could you please explain that procedure in greater details.  Dr Google was
no help to me.
Error message is "connection refused".
Thank you and have a wonderful day,
Ryan Jones
443-801-1974
On Wed, Sep 16, 2020 at 11:21 PM Rich Alberth notifications@github.com
wrote:

Many! But first, thanks for trying out my MM Minecraft plugin.
Let's start with the software on the box and work on anything on your MM
box that might be getting in the way.
Can you ping from the MM box to the Minecraft box? If that works, it
eliminates basic networking problems, but if it fails, it doesn't
necessarily mean much...firewalls can block ICMP like ping.
Give "traceroute" a try if you know that. If there is an intermediate
router between MM and Minecraft it'll let us know how far a packet can get.
If these fail, there could be a firewall or something else blocking
traffic from leaving the MM box, however unlikely that might be.
If you have "nc" installed on the MM box, or want to install it, that's
another way to check network connectivity. Something like echo "hithere"
| nc 1.2.3.4 567 where 1.2.3.4 is the Minecraft box and 567 is the port
the Minecraft software is listening on. That'll use plain TCP to connect.
Can you describe your network setup too? That can help iron out something
strange. I.e., is your MM and Minecraft box on the same network segment?
Separated by a router or switch?
Is there a specific error message you're seeing in the MM logs that could
shed some light on things? If MM-MinecraftStatus can't reach the Minecraft
server, it prints an error message in the browser's console. If you're not
familiar with that, we can run MM "serveronly" and connect from a regular
FireFox or Chrome browser and look at the console logs for something
specific.
I'm sorry, but I don't know your general level of network savvy and if
you've worked with a browser console before. Please write back and let me
know what from above sounds good, and what you're unfamiliar with. I'll
explain more in detail to get things moving!
Don't worry, we'll figure this out.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ralberth/MMM-MinecraftStatus/issues/2#issuecomment-693784468,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZO3NTFZAIWQHCI6KONPHDSGF6EFANCNFSM4RPR7MKA
.

Here's a brain dump from our phone call this evening.  Hopefully your networking friend can think of something useful!
Setup
Networks
192.168.1.* ("cove")
Main network with MagicMirror box, desktop PC, and the printers.
192.168.50.* ("scallywag")
Network with both Minecraft servers, reserved for kid-oriented servers.
"Officers"
Separate network with iPad and parent devices.
There are other networks with kid's kindles and so on.
Router Rules

Cove can connect to scallywag
Officers can connect to scallywag
Scallywag cannot connect to Cove or Officers

Servers
Minecraft Bedrock Server
IP 192.168.50.23, mask 255.255.255.0.  Ubuntu box running Bedrock.  Lives on Scallywag network.
Minecraft Java Server
IP 192.168.50.22, mask 255.255.255.0.  Pi running Bukkit Minecraft server.  Lives on Scallywag.
MagicMirror
IP 192.168.1.9, mask 255.255.255.0.  Runs Magic Mirror, lives on Cove.
Desktop PC
Windows PC also on Cove.
Goal
Get MagicMirror box to connect to Bedrock Minecraft server.  The MagicMirror software wants to check if Bedrock server is running Minecraft by checking it's port, 19132.
Status

iPad on Officers network can connect to Minecraft on Bedrock server.  Double-checked it's using 192.168.50.23 and port 19132
MagicMirror cannot connect to Minecraft on Bedrock server.

Troubleshooting

We have network connectivity from MagicMirror to Bedrock server, and it routes through the router since they are on different networks (.1. to .50.):
tracert 192.168.50.23 shows 192.168.1.1 and then 192.168.50.23.
Bedrock server rejects attempts to connect to port 19132 from MagicMirror:
telnet 192.168.50.32 19132 gives "connection refused"
so, packets are reaching the host, but the host is rejecting the connection attempt saying that there is no such open port on the server.
Confirmed that port 19132 is not listening on the Bedrock server:
netstat -ant | grep 19132 shows nothing.
Further netstat commands confirm it's not open.
Repeat the test from Minecraft Java Server since it is also on the .50. network.  This eliminates something strange with the router:
telnet 192.168.50.23 19132 also gives "connection refused"
Confirms packets can reach the Bedrock server and that there is nothing listening on that port.
Confirm Minecraft is running on the Bedrock server first hand by bounding it locally:
sudo systemctl restart minecraft (or something close to that), confirmed it restarted.
Same result as above, "connection refused".  netstat still shows nothing listening on port 19132.
Messed around with firewall rules on the router, but same result.
Confirm Minecraft is trying to listen on 19132: more server.properties on the Bedrock server and saw  server.port=19132` entry confirming it.

Everything above is consistent with the Minecraft Bedrock server having trouble starting up, resulting in all connection attempts being "connection refused".  However, the iPad continues to be able to connect.
Next Steps

Repeat everything above?
Spend more time understanding why the iPad works, look at config, how it logs-in, etc.
Dump whatever you find in here if you get stuck.  Maybe it'll trigger something else in my brain to look at.

Conclusion so far
It's cold comfort, but this isn't a MagicMirror or MM-MinecraftStatus problem, since command-line things like telnet also can't connect to the port on the Bedrock server.  Let's get connectivity at the OS working first, then see if MagicMirror has any problems.
Cheers!

Update from our troubleshooting session on Saturday night.  My friend (Joel) was able to confirm a programming language difference between the Bedrock server and MMM-MINECRAFTSTATUS.  He will reply back in greater detail but I would be willing to serve as lab rat while this script is updated or a new one is created.
A computer programmer I am not but I’m pretty good at testing and documenting results.
Ryan Jones
Sent from my iPad

On Sep 18, 2020, at 11:32 PM, Rich Alberth notifications@github.com wrote:
Here's a brain dump from our phone call this evening. Hopefully your networking friend can think of something useful!
Setup
Networks
192.168.1.* ("cove")
Main network with MagicMirror box, desktop PC, and the printers.
192.168.50.* ("scallywag")
Network with both Minecraft servers, reserved for kid-oriented servers.
"Officers"
Separate network with iPad and parent devices.
There are other networks with kid's kindles and so on.
Router Rules
Cove can connect to scallywag
Officers can connect to scallywag
Scallywag cannot connect to Cove or Officers
Servers
Minecraft Bedrock Server
IP 192.168.50.23, mask 255.255.255.0. Ubuntu box running Bedrock. Lives on Scallywag network.
Minecraft Java Server
IP 192.168.50.22, mask 255.255.255.0. Pi running Bukkit Minecraft server. Lives on Scallywag.
MagicMirror
IP 192.168.1.9, mask 255.255.255.0. Runs Magic Mirror, lives on Cove.
Desktop PC
Windows PC also on Cove.
Goal
Get MagicMirror box to connect to Bedrock Minecraft server. The MagicMirror software wants to check if Bedrock server is running Minecraft by checking it's port, 19132.
Status
iPad on Officers network can connect to Minecraft on Bedrock server. Double-checked it's using 192.168.50.23 and port 19132
MagicMirror cannot connect to Minecraft on Bedrock server.
Troubleshooting
We have network connectivity from MagicMirror to Bedrock server, and it routes through the router since they are on different networks (.1. to .50.):
tracert 192.168.50.23 shows 192.168.1.1 and then 192.168.50.23.
Bedrock server rejects attempts to connect to port 19132 from MagicMirror:
telnet 192.168.50.32 19132 gives "connection refused"
so, packets are reaching the host, but the host is rejecting the connection attempt saying that there is no such open port on the server.
Confirmed that port 19132 is not listening on the Bedrock server:
netstat -ant | grep 19132 shows nothing.
Further netstat commands confirm it's not open.
Repeat the test from Minecraft Java Server since it is also on the .50. network. This eliminates something strange with the router:
telnet 192.168.50.23 19132 also gives "connection refused"
Confirms packets can reach the Bedrock server and that there is nothing listening on that port.
Confirm Minecraft is running on the Bedrock server first hand by bounding it locally:
sudo systemctl restart minecraft (or something close to that), confirmed it restarted.
Same result as above, "connection refused". netstat still shows nothing listening on port 19132.
Messed around with firewall rules on the router, but same result.
Confirm Minecraft is trying to listen on 19132: more server.properties on the Bedrock server and saw server.port=19132` entry confirming it.
Everything above is consistent with the Minecraft Bedrock server having trouble starting up, resulting in all connection attempts being "connection refused". However, the iPad continues to be able to connect.
Next Steps
Repeat everything above?
Spend more time understanding why the iPad works, look at config, how it logs-in, etc.
Dump whatever you find in here if you get stuck. Maybe it'll trigger something else in my brain to look at.
Conclusion so far
It's cold comfort, but this isn't a MagicMirror or MM-MinecraftStatus problem, since command-line things like telnet also can't connect to the port on the Bedrock server. Let's get connectivity at the OS working first, then see if MagicMirror has any problems.
Cheers!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I didn't know Bedrock server existed before you created this issue.  When you have more info, let me know.  I'm happy to update the MagicMirror module to handle this too!

Hey Joel, Any chance you could reply back with the programming language
differences you noticed?
Thank you and have a wonderful day,
Ryan Jones
443-801-1974
On Mon, Sep 21, 2020 at 8:22 AM Rich Alberth notifications@github.com
wrote:

I didn't know Bedrock server existed before you created this issue. When
you have more info, let me know. I'm happy to update the MagicMirror module
to handle this too!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ralberth/MMM-MinecraftStatus/issues/2#issuecomment-696078868,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZO3NUX6B3HPX2CS227TKLSG5APVANCNFSM4RPR7MKA
.

Ryan,
I’d be happy to.
It’s been a few days since I was looking at the situation but the network & installation seemed fine, the reason Ryan’s setup isn’t working I think traces back to the MM, its module or maybe the dependency that the module uses to run queries.
What caught my attention was that MMM-MinecraftStatus depends on Minecraft-ping which according to the npm page was last published 5 years ago- before bedrock came out. I suppose it’s possible that the node package is capable of talking with bedrock if the API didn’t change but that’s sort of a rabbit hole. The behavior I saw was that the MM service was only ever trying to connect to Minecraft via TCP and nothing I found indicated a way to swap it over to UDP. If there’s some way to get MM to hit the right socket then maybe it’s just that easy.
Anyway, that’s what I noticed when I went over there. You guys were just missing the service when you were querying for it since telnet is tcp only and without the -u netstat is likewise only going to show tcp connections. As a suggestion, nmap is a clean way to check connectivity and running tcpdump can pretty quickly show you what sort of traffic is flowing between nodes. Regardless, good luck to you!
Thanks,
Joel
From: Ryan Jones rjdapirate@gmail.com
Date: Thursday, September 24, 2020 at 7:48 PM
To: ralberth/MMM-MinecraftStatus reply@reply.github.com, Joel Callicrate joel.callicrate@gmail.com
Subject: Re: [ralberth/MMM-MinecraftStatus] Cannot ping a Bedrock Server (#2)
Hey Joel, Any chance you could reply back with the programming language differences you noticed?
Thank you and have a wonderful day,
Ryan Jones
443-801-1974
On Mon, Sep 21, 2020 at 8:22 AM Rich Alberth <notifications@github.commailto:notifications@github.com> wrote:
I didn't know Bedrock server existed before you created this issue. When you have more info, let me know. I'm happy to update the MagicMirror module to handle this too!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/ralberth/MMM-MinecraftStatus/issues/2#issuecomment-696078868, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQZO3NUX6B3HPX2CS227TKLSG5APVANCNFSM4RPR7MKA.

Wow, you probably found it!   We were looking for a TCP connection and using tools to connect to an assumed TCP socket instead of sending plain UDP datagrams.
The current MinecraftStatus certainly won't work with Bedrock, but this is a great feature to add.  I'll get to it "soon" :-)
I'm out this entire weekend, and next week sucks, but I'll get a feature out to handle it.
Joel, THANK YOU for doing the work on your side and helping!

Thank you my friend.
Have a great Day,
Ryan A. Jones

On Sep 25, 2020, at 4:57 PM, J C joel.callicrate@gmail.com wrote:

Ryan,
I’d be happy to.
It’s been a few days since I was looking at the situation but the network & installation seemed fine, the reason Ryan’s setup isn’t working I think traces back to the MM, its module or maybe the dependency that the module uses to run queries.
What caught my attention was that MMM-MinecraftStatus depends on Minecraft-ping which according to the npm page was last published 5 years ago- before bedrock came out. I suppose it’s possible that the node package is capable of talking with bedrock if the API didn’t change but that’s sort of a rabbit hole. The behavior I saw was that the MM service was only ever trying to connect to Minecraft via TCP and nothing I found indicated a way to swap it over to UDP. If there’s some way to get MM to hit the right socket then maybe it’s just that easy.
Anyway, that’s what I noticed when I went over there. You guys were just missing the service when you were querying for it since telnet is tcp only and without the -u netstat is likewise only going to show tcp connections. As a suggestion, nmap is a clean way to check connectivity and running tcpdump can pretty quickly show you what sort of traffic is flowing between nodes. Regardless, good luck to you!
Thanks,
Joel
From: Ryan Jones rjdapirate@gmail.com
Date: Thursday, September 24, 2020 at 7:48 PM
To: ralberth/MMM-MinecraftStatus reply@reply.github.com, Joel Callicrate joel.callicrate@gmail.com
Subject: Re: [ralberth/MMM-MinecraftStatus] Cannot ping a Bedrock Server (#2)
Hey Joel, Any chance you could reply back with the programming language differences you noticed?
Thank you and have a wonderful day,
Ryan Jones
443-801-1974
On Mon, Sep 21, 2020 at 8:22 AM Rich Alberth notifications@github.com wrote:
I didn't know Bedrock server existed before you created this issue. When you have more info, let me know. I'm happy to update the MagicMirror module to handle this too!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I stand ready to be the lab rat.
Have a great Day,
Ryan A. Jones

On Sep 25, 2020, at 6:18 PM, Rich Alberth notifications@github.com wrote:

Wow, you probably found it! We were looking for a TCP connection and using tools to connect to an assumed TCP socket instead of sending plain UDP datagrams.
The current MinecraftStatus certainly won't work with Bedrock, but this is a great feature to add. I'll get to it "soon" :-)
I'm out this entire weekend, and next week sucks, but I'll get a feature out to handle it.
Joel, THANK YOU for doing the work on your side and helping!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I did some research.  According to the BDS wiki on gamepedia.com,

BDS uses UDP
BDS is Alpha software
No RCON
No libraries for remote control

The main BDS download page on minecraft.net  says this is an early alpha release for evaluation only.
So, I'm not surprised there isn't support for it in the usual libraries yet.
I posted to Reddit's /r/MCPE asking about similar BDS libraries.  Let's wait and see if there is something out there, or other ideas before we go further.
https://www.reddit.com/r/MCPE/comments/j3lhdh/rcon_to_bedrock_or_other_way_to_query_from_remote/

Copy that
Have a great Day,
Ryan A. Jones

On Oct 1, 2020, at 9:26 PM, Rich Alberth notifications@github.com wrote:

I did some research. According to the BDS wiki on gamepedia.com,
BDS uses UDP
BDS is Alpha software
No RCON
No libraries for remote control
The main BDS download page on minecraft.net says this is an early alpha release for evaluation only.
So, I'm not surprised there isn't support for it in the usual libraries yet.
I posted to Reddit's /r/MCPE asking about similar BDS libraries. Let's wait and see if there is something out there, or other ideas before we go further.
https://www.reddit.com/r/MCPE/comments/j3lhdh/rcon_to_bedrock_or_other_way_to_query_from_remote/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Ugh, no replies on the reddit post after over a week.  I posted on the Minecraft #technical-bedrock Discord group, but didn't get anywhere.  I think this will have to be a feature request and sit for a while until we get more community over time that contributes to plugins, etc. that can handle this.
Sorry for the dead-end right now.  I'll leave the issue open so it gets attention from time-to-time, and see if I can find some support in the future.  Cheers!

authors: RJDaPirate ralberth

repo: ralberth/MMM-MinecraftStatus


text:
Refactoring SchemaCollection to allow any kind of schema + internal code simplification

Hi,
The main purpose of this PR is to allow any kind of schema to be defined within SchemaCollection. Along the way, I also simplified some internal logic to simplify the code.
This PR does not introduce any breaking changes!
The new recommended and documented way to add schema is now as follows:
use RalphJSmit\Laravel\SEO\SchemaCollection;

public function getDynamicSEOData(): SEOData
{
    return new SEOData(
        // ...
        schema: SchemaCollection::make()->add(fn(SEOData $SEOData) => [
            '@context' => 'https://schema.org',
            '@type' => 'FAQPage',
            'mainEntity' => [
                '@type' => 'Question',
                'name' => 'Your question goes here',
                'acceptedAnswer' => [
                    '@type' => 'Answer',
                    'text' => 'Your answer goes here',
                ],
            ],
        ]),
    );
}

Additionally, this PR comes with 2 presets that replace addArticle and addBreadcrumbs.
Here's an example using withArticle:
use RalphJSmit\Laravel\SEO\SchemaCollection;
use RalphJSmit\Laravel\SEO\Support\SEOData;
use Illuminate\Support\Collection;

public function getDynamicSEOData(): SEOData
{
    return new SEOData(
        // ...
        title: "A boring title"
        schema: SchemaCollection::make()->withArticle(function(SEOData $SEOData, Collection $article){
            return $article->mergeRecursive([
                'alternativeHeadline' => "Not {$SEOData->title}", // will be "Not A boring title"
                'author' => [
                    [
                        '@type' => 'Person',
                        'name' => $this->moderator,
                    ]
                ]
            ]);
        }),
    );
}

I admit that this new way of modifying preconfigured schema is not entirely ideal. It could be greatly improved by defining new classes that extend Collection and support methods similar to the current Article.
However, considering the complexity of supporting every schema key in a fluent way, I'm not entirely convinced it's necessary at this time.

I managed to refactor ArticleSchema and BreadcrumbListSchema to make them use SchemaTag (renamed from CustomSchema) without any breaking changes !!
I'm pretty happy with the result as the new Schema paradigm is now more fluent, extensible and simple to me

Hey @ralphjsmit did you get a chance to look at it ?

Sorry, not yet, likely next week.

Hi Quentin! Thanks for your patience, I came back to the PR today and reviewed it. In the end I decided to keep the fluent methods for article, breadcrumb list and faq page, because I think having these as options for fluent classes is valuable for developers as well, because it provides them with auto-completed fluent methods for the most common things to change, without having to remember the exact keys and format needed for these. I did refactor these 3 fluent classes to extend the CustomSchema paradigm, so we just have one paradigm for JSON schemas, and in the future if someone ever wants to create new fluent CustomSchema classes, they can just be added as easily. The with*() methods I did remove, so we ended up with 4 methods ->add(), ->addArticle(), ->addBreadcrumbs() and ->addFaqPage(), which I think is a nice combination. The FaqPage I also added back, since we already had it merged and I like the auto-completed syntax of it (why force people to manually construct an array if they can also use one neat method).
I just released it in 1.6.0, together with the alternate tag PR. Thanks for providing the PR to make it easier to add custom schemas! :)

@ralphjsmit Great! thank you very much 🙏

authors: QuentinGab ralphjsmit

repo: ralphjsmit/laravel-seo


text:
Duplicated transducer init and result functions

This has been mentioned elsewhere, but there doesn't seem to be an open issue about it.
The plain reducer init function is apparently used 13 places in Ramda:
grep -r "return this.xf\['@@transducer/init']()"
_xtake.js:    return this.xf['@@transducer/init']();
_xall.js:    return this.xf['@@transducer/init']();
_xmap.js:    return this.xf['@@transducer/init']();
_xfind.js:    return this.xf['@@transducer/init']();
_xfilter.js:    return this.xf['@@transducer/init']();
_xgroupBy.js:    return this.xf['@@transducer/init']();
_xtakeWhile.js:    return this.xf['@@transducer/init']();
_xdrop.js:    return this.xf['@@transducer/init']();
_xany.js:    return this.xf['@@transducer/init']();
_xdropWhile.js:    return this.xf['@@transducer/init']();
_xfindLastIndex.js:    return this.xf['@@transducer/init']();
_xfindLast.js:    return this.xf['@@transducer/init']();
_xfindIndex.js:    return this.xf['@@transducer/init']();

Maybe default init and result functions should be defined in a helper file to avoid the repetition?

absolutely yes.
While we're at it, there are a number of redundant @@transducer/result functions as well:
https://github.com/ramda/ramda/search?utf8=✓&q=return+this.xf['%40%40transducer%2Fresult'](result\)%3B&type=Code

But, where should the helper functions be located? The current scheme seems to be one file in src/internal/ per helper function.
But separating these two functions across two files might be overkill?

i think something like this would be fine:
// file: src/internal/_xfBase.js
module.exports = {
   init: function() { return this.xf['@@transducer/init'](); },
   result: function(result) { return this.xf['@@transducer/result'](result); }
};

then:
var _xfBase = require('./_xfBase');

// .... :
XThing.prototype.init = _xfBase.init
XThing.prototype.result = _xfBase.result
// etc.

Yes. I agree. I'll create a pull request if you don't mind.

sounds good, thank you

fixed in #1022

authors: buzzdecafe paldepind

repo: ramda/ramda


text:
partial support for Map

As proposed in #1055. I'm opening this pull request for discussion. I've implemented a handful of "object" functions for Map. The remaining "object" functions could be implemented fairly easily, I imagine.

I definitely like this better than the idea of internal "switch" operations.  It's starting to scare me a bit less.
The interesting next take of course would be to see where our list functions could work on any arbitrary iterable...

The interesting next take of course would be to see where our list functions could work on any arbitrary iterable...

we are already supporting iterables via transducers

:-1:

:100: This looks great!

+1

let's pull this post 0.14 or start an ES6 branch

Post v0.14.0 I'll update this pull request to support Map objects in the remaining Object functions. On a related note, functions such as R.intersection and R.union should support Set objects. :)

Post v0.14.0 I'll update this pull request to support Map objects in the remaining Object functions.

we are in the post-0.14 era :smile:

I should revive this pull request.

:herb:

This pull request is squatting on a useful branch name, so I'll close it for now. I do hope to come back to this one day.

authors: CrossEye benperez buzzdecafe davidchambers wayneseymour


text:
remove R.installTo

I've never liked this function, as it promotes what I believe to be a bad practice, but I haven't felt compelled to remove it until now. #829 makes a good case for allowing modules to be required individually; #833 revealed that R.installTo does not (and perhaps cannot) work when used this way.
Let's remove the one function in the library which breaks referential transparency.

Like in the discussion for removing propOf: if this is to be removed, please consider deprecating it first. It just seems like good practice.
https://github.com/ramda/ramda/pull/831#issuecomment-75371284

please consider deprecating it first

That's fine with me. It remains to be seen whether we'll remove it at all. ;)

I'm going to suspect that I'm the only one who would really miss this.
It's here because this is how I like to work.  I know that it doesn't work for everyone, and that using it the way I prefer could lead to conflicts with other functions, but I simply prefer this:
pipe(identifierToFilename,
       parse,
       prop('ast'),
       prop('body'),
       takeWhile(where({type: 'VariableDeclaration', kind: 'var'})),
       pluck('declarations'),
       map(tap($pathEq('length', 1))),
       map(head),
       map(tap($pathEq('init.type', 'CallExpression'))),
       map(tap($pathEq('init.callee.type', 'Identifier'))),
       map(tap($pathEq('init.callee.name', 'require'))),
       map(tap($pathEq('init.arguments.length', 1))),
       map(tap($pathEq('init.arguments.0.type', 'Literal'))),
       tap(pipe(pluck('id'),
                    pluck('name'),
                    converge(assert.deepEqual,
                               I,
                               sortBy(I)))),
       map(tap(converge(assert.strictEqual,
                              path('id.name'),
                              pipe(path('init.arguments.0.value'),
                                     replace(/^[.][/]internal[/]/, './'),
                                     replace(/^[.]{1,2}[/]/, ''),
                                     replace(/[.]([a-z])/g,
                                               pipe(nthArg(1),
                                                      toUpper)))))),
       map(path('id.name')));

to this:
R.pipe(identifierToFilename,
       parse,
       R.prop('ast'),
       R.prop('body'),
       R.takeWhile(R.where({type: 'VariableDeclaration', kind: 'var'})),
       R.pluck('declarations'),
       R.map(R.tap($pathEq('length', 1))),
       R.map(R.head),
       R.map(R.tap($pathEq('init.type', 'CallExpression'))),
       R.map(R.tap($pathEq('init.callee.type', 'Identifier'))),
       R.map(R.tap($pathEq('init.callee.name', 'require'))),
       R.map(R.tap($pathEq('init.arguments.length', 1))),
       R.map(R.tap($pathEq('init.arguments.0.type', 'Literal'))),
       R.tap(R.pipe(R.pluck('id'),
                    R.pluck('name'),
                    R.converge(assert.deepEqual,
                               R.I,
                               R.sortBy(R.I)))),
       R.map(R.tap(R.converge(assert.strictEqual,
                              R.path('id.name'),
                              R.pipe(R.path('init.arguments.0.value'),
                                     R.replace(/^[.][/]internal[/]/, './'),
                                     R.replace(/^[.]{1,2}[/]/, ''),
                                     R.replace(/[.]([a-z])/g,
                                               R.pipe(R.nthArg(1),
                                                      R.toUpper)))))),
       R.map(R.path('id.name')));

There is one huge benefit, though, of removing it: it is the only function that modifies user input data.  Granted it's a very special case, meant for very different use than the rest of the functions in the library.  But it really would be nice to give a categorical statement that Ramda never modifies user data.
I guess I'd probably have to give it a reluctant :+1: and keep it in my back pocket for my own use, but I would like to hear if there are others using it.

it is nice to import the names into global space, but i don't think it's worth it either. i also agree with @TheLudd that we should deprecate and warn for a minor version or two and then remove.
:cow2:

It could also be kept in another project, let's say we call it ramda-dirty-stuff. Where these kind of non pure functions could live.

we have an incipient "impure" extension. "dirty-stuff" might get more hits though :smiley_cat:
The "impure" extension has languished, probably because none of us is particularly interested in enabling mutating, imperative code.

First of all, thanks a lot for the amazing library! We use it on production at work, and it's amazing.
I also prefer writing code like @CrossEye , without all those R., so we just write in the beginning of each module:
var get = R.get;
var compose = R.compose;
var pCompose = R.pCompose;
var assoc = R.assoc;

For each function we use. It's not pretty to have all that in the beginning of the file, but we feel our actual code gains A LOT by not being written with a lot of R., and we still do not have everything global.
My coworker @jsanchesleao is eager to use ES6 destructuring for that:
{get, compose, pCompose, assoc} = R;
One more time, thank you very much! :)

[T]hanks a lot for the amazing library!

I :heart: enthusiastic, appreciative users. Ramda would not exist in its current form were it not for numerous suggestions and improvements from the community. Thank you for being part of it.
Using destructuring assignment on a module-by-module basis is an elegant way to enjoy R.-free programming. :)

:+1:

@lucasmreis @CrossEye
Regarding R.-free programming in a browser I'd like to throw this snippet in:
R.map(function(funcName){
		window[funcName] = R[funcName];
	},
	R.difference(R.functions(R), R.keysIn(window))
);

window.R = R; // for the rest of things (right now it's find and length)

@semmel: Nice!  I use a slightly different technique, but similar enough.
I've never bothered with the R.difference bit, but it makes sense in case we step on the toes of something important.  (I personally never use window.length or window.find.)  For the foreseeable future, the only difference between R.keysIn(R) and R.functions(F) is the existence of the placeholder __ in the former.  That's one I definitely want available; others who do as well should simply switch functions here.

@semmel: I always try not to put functions on window, but maybe it's just an unnecessary fear! ;)

@CrossEye I too hadn't bothered with R.difference(R.keysIn(R), R.keysIn(window)) until I've recently discovered that the Stock Android 4.2 Browser doesn't let you reassign the window.length property.
I.e.
window["length"] = function dummy(){ return undefined; }
typeof length // "number" in Stock Android 4.22 Browser, "function" everywhere else

Thus if you target that browser you must always use R.length because the global length is not writable.
@lucasmreis

I always try not to put functions on window, but maybe it's just an unnecessary fear! ;)

Why is that? Since I doubt that there is a this in any Ramda function implementation pointing to R, I guess it's the same as simply writing
<script>
function foo(){ bar(); }
function isEmpty(list) {
    return Object(list).length === 0;
};
</script>

or is it not?

You're right. That example is a simple explanation of how unnecessary the fear is. :+1:

authors: CrossEye TheLudd buzzdecafe davidchambers lucasmreis semmel


text:
Let us choose the browser for lookups with 'S'

would be be nice if we could specify the browser in a config file or something instead of using the default browser.

personally i use different browser for different things. for example: one browser for language learning, another for google services, yet another for web browsing and so on and i have them open in different windows desktop environments as well.
only have the necessary add-ons in my language learning browser

Implemented in https://github.com/rampaa/JL/commit/548c66c087939a404d207bc5382eb3f26b3e1a2e, will be included in the next release.

authors: AsuraAce rampaa

repo: rampaa/JL


text:
Node of UUID is 0

I'm using uuid-doctrine with UuidBinaryOrderedTimeType as an id field on multiple sql tables, which is working fine on a local dev environment. When using same code on the prod server (identical config, versions etc) the node of each UUID is always just 0.
How do I debug/ how can I get any more info of this problem, as to why the node is always zero'd? Unfortunately there is no exception thrown...

php-fpm 7.4, ramsey/uuid-doctrine 1.8.1, doctrine/orm 2.13.2

After digging through the sources, I've found the issue. The origin is in ramsey/uuid instead of the uuid-doctrine. It seems that there has been an issue in 2016 about this: ramsey/uuid#133.
The server is running on a vpn network, which interface hasn't got a mac address (as in: 00-00-00-00-00-00). As this interface is the first one listed by SystemNodeProvider->getIfconfig() it takes the mentioned zeroed mac address as the returned node.
When going through the interfaces, I've put a quick if-statement to it:
Ramsey\Uuid\Provider\Node\SystemNodeProvider.php line 138
        if (preg_match_all(self::IFCONFIG_PATTERN, $ifconfig, $matches, PREG_PATTERN_ORDER)) {
            foreach($matches[1] as $iface) {
                if($iface!="00-00-00-00-00-00"){
                    $node = $iface;
                }
            }
        }

This cycles through all interfaces and takes the first "usable" one, while dismissing zero'd entries.

repo: ramsey/uuid-doctrine


text:
Add rule for UIPlugin resources in default ResourceSet

This PR seeks to resolve issue #483
Test Steps

In a local cluster with the Kamaji UI extension installed, manually edited the default ResourceSet to include the new rule for UIPlugins.
Took a backup (B1)
See if B1 correctly includes the Kamaji UIPlugin
Create a new cluster and restore the backup as detailed here
Once restored, enable extensions in the new cluster and reload the page. Check if Kamaji UI remains correctly installed.

/backport v2.8-Next2 release/v4.0

/backport v2.7-Next2 release/v3.0

authors: jbiers mallardduck

repo: rancher/backup-restore-operator


text:
How did you get loop mounting to work?

When I ran a build using dapper (e.g. RancherOS), I am able to do loop mounts. Yet those capabilities normally are missing from Docker containers. How does Dapper allow loopback mounts? I see nothing about added capabilities anywhere, so how does it do it?

Ah, never mind. You added ENV DAPPER_RUN_ARGS --privileged. Cute.

repo: rancher/dapper


text:
Add-On Config Area UX Improvements: Additional Manifest Section Visibility in Add-on Config area

Setup

Rancher version: 2.9.1
Rancher UI Extensions:
Browser type & version: any

Describe the bug

The Additional Manifest section in the RKE2 cluster configuration dashboard's "Add-On Config" area is frequently overlooked by users due to its location further down the page. Many customers fail to notice, resulting in missed configurations. Additionally, the form-based editor does not provide a clear or user-friendly way to interact with the additional manifest settings, confusing users accustomed to direct YAML editing.
To Reproduce

create custom rke2 cluster with CNI: cilium
Click on the Edit Config and click on "Add-on Config" under Cluster Configuration

Result
The additionalManifest section is hidden further down the "Add-On Config" area
Expected Result

The additionalManifest section should be more prominent and easily accessible, potentially through a collapsible or drop-down UI element that makes it clear or add another tab for additional manifest
Screenshots

maybe something like this:

Additional context

Internal ref: SURE-8962

@gaktive @dkeightley Looks like this has been implemented here
https://github.com/rancher/dashboard/issues/12066
I can confirm on 2.10 cluster:

Yes, thanks! I noticed it was also added in ~v2.9.4

authors: dkeightley skanakal

repo: rancher/dashboard


text:
2.6 UX: Bring together V2 Cluster Provisioning with Ember-embedded V1

Need a combined cluster list that shows V2 and V1 clusters.
Need to ensure that V1 embedding appears correctly when V2 is turned on and off via the tech preview/beta flag

Test report:
TL;DR - it works as described above. I was testing mainly with legacy flag turned off (but also tried to turn it on) and I was altering between RKE/RKE2 switch and RKE2 feature flag - both ways are offering only the corresponding UIs for provisioning/importing a cluster - Vue and/or Ember.

I didn't try to provision anything apart Hosted clusters (AKS, EKS, GKE) to make sure that backend resources are fetched correctly when iframes are used & custom RKE2 single node cluster.
I was creating credentials and templates for cloud provisioners within cluster definition (not always - sometimes I used existing ones) to make sure the data are propagated correctly into rancher.

I identified following related bugs during my testing:

NEW https://github.com/rancher/rancher/issues/33343 Problems with loading RKE1 Configuration iframes in Dashboard
EXISTING https://github.com/rancher/dashboard/issues/3145 No easy way for displaying reg. command for existing RKE1 in Dashboard

Create cluster scenario:

Hosted Kubernetes - always iframe: EKS, AKS, GKE (AKS failed for unknown reason - but v2 is ongoing, GKE failed due https://github.com/rancher/rancher/issues/33241, AKS worked)
RKE2 node drivers - all Vue: EC2, AZURE, DO, Linode (no support yet but it is active), vSphere (no env to test - fake credentials not accepted)
RKE1 node drivers - all iframe: EC2, Azure, DO, Linode, vSphere (fake creds accepted but ofc vsphere res not fetched)
Custom RKE2 cluster - Vue: I was able provision custom RKE2 single-node cluster with all roles set
Custom RKE1 cluster - iframe: the reg. command looks ok - but no easy way to get reg. command again due https://github.com/rancher/dashboard/issues/3145

Import existing cluster scenario:

Hosted Kubernetes - always iframe: EKS, AKS, GKE - it offers a list of "cluster To register" when credentials are provided/created in given region
Generic - Vue: kubectl command(s) are showing up after a while in Registration tab

Closing.

authors: nwmac thehejik


text:
Add last used column for API tokens

Summary
Fixes #11870
Occurred changes and/or fixed issues
The PR adds the 'Last Used' information for API tokens, as implemented by this backend PR: https://github.com/rancher/rancher/issues/45732
Technical notes summary
Fairly simple - we define a new column and add it to the API Keys/Tokens table. Added translation as aell.
Areas or cases that should be tested

Go to the API Keys from the user preference menu (top right avatar)
Verify that the tokens table included a 'Last Used' column
Check the column sorting works correctly
Hover over one of the Last Used cells and check that a tooltip appears, showing the absolute date/time

Screenshot/Video

New 'Last Used' column:

Hover on last used shows absolute date/time:

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

@richard-cox Backend is not merge - I tested with a locally built Rancher from the backend PR.


text:
Increase the verbocity of logging output within k3s_release modify-k3s

While running k3s_release modify-k3s there is no logging output or errors reported upon failure. By enabling and increasing verbosity within this command users can better understand what is happening during runtime.

Completed via #169

authors: briandowns nikolaishields

repo: rancher/ecm-distro-tools


text:
Add rancher search domain before host domains

This PR changes the order of the search domain passed to each container's resolv.conf. Essentially, we believe that rancher.internal should be searched before any host search domains.
Here's the use case we hit upon:

Assume that the host machine has the search domain: "search foobar.com"
Assume that a wildcard domain (*.foobar.com) exists and points to "biz.foobar.com"
Launch a new service in rancher, then execute a shell on it and type: "ping rancher-metadata"

The above would resolve to "biz.foobar.com" which is not what was intended.

This is something that would need to be  conditional based on a setting (or similar), and default to the existing behavior.
There are companies with useful search paths and applications/people that rely on them, which is why we have always been conservative and put ourselves last.

Very stale. Closing

authors: cjellick nunofgs vincent99

repo: rancher/host-api


text:
Permission denied during auto installation

Version v0.10.2
Architecture
Virtual Maschine
Describe the bug
I generated a new ISO file with modified grub.cfg to activate the auto installer
set default=0
set timeout=10

set gfxmode=auto
set gfxpayload=keep
insmod all_video
insmod gfxterm

menuentry "k3OS LiveCD & Installer" {
  search.fs_label K3OS root
  set sqfile=/k3os/system/kernel/current/kernel.squashfs
  loopback loop0 /$sqfile
  set root=($root)
  linux (loop0)/vmlinuz printk.devkmsg=on k3os.mode=install k3os.fallback_mode=install console=ttyS0 console=tty1k3os.install.debug=true
  initrd /k3os/system/kernel/current/initrd
}

menuentry "k3OS Rescue Shell" {
  search.fs_label K3OS root
  set sqfile=/k3os/system/kernel/current/kernel.squashfs
  loopback loop0 /$sqfile
  set root=($root)
  linux (loop0)/vmlinuz printk.devkmsg=on rescue console=ttyS0 console=tty1
  initrd /k3os/system/kernel/current/initrd
}

During the installation process I get the error message ``` /usr/libexec/k3os/boot: line 71: /sbin/k3os: Permission denied
To Reproduce

Copy the /boot/grub and k3os/system from the original iso image.
Edit the grub.cfg as described above.
Create a new iso image with grub-mkrescue -o k3os-new.iso iso_img/ -- -volid K3OS
Try to boot from this image

Expected behavior

I expected that the auto installer will start and install the system.

Actual behavior

Installation stops with error code

Additional context

ISO image is build form a ubuntu system.
Installation is done within a VM ware.

Solved by setting the permissions of the copied data to chmode 777


text:
Engine 0.3.0 is being installed when installing 0.3.1 via catalog

Hi, I'm new to here, please correct me if I'm wrong.
I've installed Longhorn from Catalog. It's installed successfully.

However If I click that ingress address it redirects me to longhorn's dashboard. It surprised me that it even has its own dashboard, wow great. But it doesn't seem to have any authentication? Is it open to world? Hmm, then I went to settings/engine image.
It shows it's using longhorn-engine:v0.3.0, wait but didn't I just install v0.3.1?

Edit: There is deploy engine image button , If I deploy latest image 0.3.1 using this tool, do I required to change something elsewhere? Or it just works?

Your deployment is correct. We're using Engine v0.3.0 for v0.3.1 as the release note mentioned.
The version of the engine may not be in sync with the version of the Longhorn release. I am considering separate it out.
The reason is a new tag for the engine means the user all needs to upgrade to the new engine image. We have live upgrade feature but it’s still experimental. And we don’t want to disturb volume’s normal operation by asking users to shut down the workload in order to upgrade the engine. So unless it's absolutely necessary we'd like to avoid engine upgrade as much as possible.

Ah I see. Thanks for the explanation. I've tried to upgrade to 0.3.1 manual. But old 0.3.0 containers didn't turn off, new ones also appeared at same time. My workload was flooded with containers. I'm not sure if it's correct or what not. As you explained, I will stick to the default options until I get deep understanding and project become more mature.
How about Longhorn authentication? It was open to public once I setup.

In the next stable release we will use Rancher mechanism to help on the authentication, so the user will need to login into Rancher before accessing the Longhorn UI.
What do you by manually? If you're using the Upgrade Engine option, that's our live engine upgrade feature, which swaps the engine while keeping volume in the working condition. It's still experimental. You shouldn't have replica running with engine v0.3.0 if it works correctly.

authors: shinebayar-g yasker

repo: rancher/longhorn


text:
External DB Password visible

Rancher versions:
rancher/server: 1.6.12
rancher/agent: N/A
Infrastructure Stack versions:
healthcheck: v0.3.3
ipsec:v0.13.5
network-services:
rancher/metadata:v0.9.5
rancher/network-manager:v0.7.18
scheduler:v0.8.2
kubernetes (if applicable): N/A
Docker version: (docker version,docker info preferred)
$ docker info
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 17.09.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-1043-aws
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 990.9MiB
Name: ip-10-0-0-58
ID: OGE4:6JUL:LEEA:QTOD:NDQC:UE2E:5OLE:I3VL:4YIK:DLHY:PNDH:NONJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Operating system and kernel: (cat /etc/os-release, uname -r preferred)
$ uname -r
4.4.0-1043-aws

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
AWS
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
For the time being, just the Rancher Server
Environment Template: (Cattle/Kubernetes/Swarm/Mesos)
N/A
Steps to Reproduce:

Log in to the host running the rancher/server container
Get the id of the rancher/server container
execute docker inspect <container_id>

Results:
The full string used to attach the external db including the password is visible in plain text

I think it'd be a nice feature to enable something like
--db-pass-file=

so we could use docker secret to store such information and the password would be no longer visible in plain text. The official mysql and postgres container work like this. So maybe rancher could offer this too.

Supporting taking a secret is fine, but the use-case is something like being able to have a compose file describe the server without having the password in it.  Which doesn't come up all that often for us since you are bootstrapping an orchestration system itself.
If someone is on the host and able to talk to the docker daemon, they are root on that machine and you've already lost.. they can just run docker exec container_id cat path_to_pass_file  to get it.  Or launch their own container using the same secret.  Or tcpdump the MySQL connection, scan through all the memory, etc

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.

authors: loganhz pkaramol ptrunk vincent99

repo: rancher/rancher


text:
Panic after adding a node to a custom cluster

Rancher versions:
rancher/rancher:2.0.0.-rc1
Steps to Reproduce:

Create a custom cluster using private registry
After the cluster comes up, add another custom node with all roles(control, etcd, worker)

Server crashes with the below panic:
2018/04/27 18:42:24 [INFO] Updating cluster [c-btrmx]
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: Building Kubernetes cluster
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [dialer] Setup tunnel for host [206.189.163.18]
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [dialer] Setup tunnel for host [159.65.37.70]
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [state] Found local kube config file, trying to get state from cluster
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [state] Fetching cluster state from Kubernetes
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [state] Successfully Fetched cluster state to Kubernetes ConfigMap: cluster-state
2018/04/27 18:42:25 [INFO] cluster [c-btrmx] provisioning: [certificates] Getting Cluster certificates from Kubernetes
panic: runtime error: index out of range

goroutine 6967046 [running]:
github.com/rancher/rancher/vendor/github.com/rancher/rke/cluster.getClusterCerts(0xa8524e0, 0xc447601080, 0xc452c844e0, 0xc449c4d040, 0x2, 0x2, 0x0, 0xc4443d8600, 0x0)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/rke/cluster/certificates.go:134 +0xab7
github.com/rancher/rancher/vendor/github.com/rancher/rke/cluster.(*Cluster).GetClusterState(0xc4443d8600, 0xa8524e0, 0xc447601080, 0x0, 0x0, 0x0)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/rke/cluster/state.go:71 +0x42f
github.com/rancher/rancher/vendor/github.com/rancher/rke/cmd.ClusterUp(0xa8524e0, 0xc447601080, 0xc450815400, 0xc4274001c0, 0xc4274001d0, 0xc455d0c220, 0x0, 0xc450530270, 0x2e, 0x0, ...)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/rke/cmd/up.go:71 +0x191
github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/drivers/rke.(*Driver).Update(0xc420490000, 0xa8524e0, 0xc447601080, 0xc4414f13f0, 0xc455c97c60, 0x0, 0x0, 0x0)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/drivers/rke/rke_driver.go:182 +0x268
github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/types.(*GrpcServer).Update(0xc420152160, 0xa8524e0, 0xc443633bc0, 0xc441142f10, 0xc420152160, 0x0, 0x0)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/types/rpc_server.go:55 +0x79
github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/types._Driver_Update_Handler(0x4ad72c0, 0xc420152160, 0xa8524e0, 0xc443633bc0, 0xc4530e0230, 0x0, 0x0, 0x0, 0x433d64, 0xc446401200)
	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/kontainer-engine/types/drivers.pb.go:598 +0x276
github.com/rancher/rancher/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc420157760, 0xa867460, 0xc44d1f4a80, 0xc455e5d540, 0xc420a1b410, 0xa7f67b8, 0x0, 0x0, 0x0)
	/go/src/github.com/rancher/rancher/vendor/google.golang.org/grpc/server.go:921 +0x96e
github.com/rancher/rancher/vendor/google.golang.org/grpc.(*Server).handleStream(0xc420157760, 0xa867460, 0xc44d1f4a80, 0xc455e5d540, 0x0)
	/go/src/github.com/rancher/rancher/vendor/google.golang.org/grpc/server.go:1143 +0x1528
github.com/rancher/rancher/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc44c2647e0, 0xc420157760, 0xa867460, 0xc44d1f4a80, 0xc455e5d540)
	/go/src/github.com/rancher/rancher/vendor/google.golang.org/grpc/server.go:638 +0x9f
created by github.com/rancher/rancher/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
	/go/src/github.com/rancher/rancher/vendor/google.golang.org/grpc/server.go:636 +0xa1

Tested with v2.0.0-rc3. Created a single node cluster(all roles) using private registry. After the cluster was created successfully, added another node with all roles.
The node got added successfully without any panic. Workloads were also created fine.


text:
sticky session with nested load balancers

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Create Rancher 1.6 cattle cluster
Create 1 public load balancer
Create 2 internal only load balancers
Create the following rules
End user -> Public LB -> Internal LB -> Application

Result:
Requests will bounce between both internal LBs
Other details that may be helpful:
We did add the following to the custom config with no change.
load_balancer_config:
lb_cookie_stickiness_policy:
cookie: persistencecookie
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v1.6.17
Installation option (single install/HA): HA

As 1.6 is EOL as of June 30, 2020, we are closing 1.6 issues.

authors: deniseschannon mattmattox


text:
cluster-monitoring is being constantly re-deployed

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):
I'm using single node Rancher v2.2.2 to manage a 5 node custom cluster.
Rancher has been continuously upgraded since v2.0.something.
Since v2.2.0, I've deployed cluster monitoring.
Result:
When looking at the Rancher server logs, I notice that the cluster-monitoring app constantly gets redeployed (therefore it's at release v2150 already).
Other details that may be helpful:
Rancher server log:

[main] 2019/05/02 12:34:10 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/05/02 12:34:10 GRPC listening on :44913
[main] 2019/05/02 12:34:10 Probes listening on :40971
[main] 2019/05/02 12:34:10 Storage driver is ConfigMap
[main] 2019/05/02 12:34:10 Max history per release is 0
[tiller] 2019/05/02 12:34:12 getting history for release cluster-monitoring
[storage] 2019/05/02 12:34:12 getting release history for "cluster-monitoring"
2019-05-02 12:34:13.054867 W | etcdserver: apply entries took too long [104.778757ms for 1 entries]
2019-05-02 12:34:13.054902 W | etcdserver: avoid queries with large range/delete range!
2019/05/02 12:34:19 [INFO] Handling backend connection request [c-dx942]
W0502 12:34:31.905776       6 reflector.go:270] github.com/rancher/norman/controller/generic_controller.go:175: watch of *v1.ServiceAccount ended with: too old resource version: 43215153 (43215177)
W0502 12:34:37.406333       6 reflector.go:270] github.com/rancher/norman/controller/generic_controller.go:175: watch of *v1beta2.StatefulSet ended with: too old resource version: 42263581 (43215140)
[tiller] 2019/05/02 12:34:53 preparing update for cluster-monitoring
[storage] 2019/05/02 12:34:53 getting deployed releases from "cluster-monitoring" history
[storage] 2019/05/02 12:34:56 getting last revision of "cluster-monitoring"
[storage] 2019/05/02 12:34:56 getting release history for "cluster-monitoring"
2019-05-02 12:35:05.341889 W | etcdserver: apply entries took too long [159.086638ms for 1 entries]
2019-05-02 12:35:05.350246 W | etcdserver: avoid queries with large range/delete range!
I0502 12:35:08.220692       6 trace.go:76] Trace[893457890]: "List /apis/batch/v1/jobs" (started: 2019-05-02 12:35:06.995935195 +0000 UTC m=+346.801612872) (total time: 1.194511788s):
Trace[893457890]: [564.459245ms] [564.459245ms] About to List from storage
Trace[893457890]: [1.155893531s] [591.434286ms] Listing from storage done
I0502 12:35:08.693135       6 trace.go:76] Trace[1148687621]: "Get /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:35:07.123719087 +0000 UTC m=+346.929396864) (total time: 1.569368849s):
Trace[1148687621]: [922.22788ms] [922.22788ms] About to Get from storage
Trace[1148687621]: [1.560869836s] [638.641956ms] About to write a response
I0502 12:35:08.799540       6 trace.go:76] Trace[604434125]: "Get /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:35:06.995889195 +0000 UTC m=+346.801566972) (total time: 1.8035294s):
Trace[604434125]: [1.025679936s] [1.025679936s] About to Get from storage
Trace[604434125]: [1.697771742s] [672.091806ms] About to write a response
I0502 12:35:09.247551       6 trace.go:76] Trace[999981084]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:35:08.54257431 +0000 UTC m=+348.348259587) (total time: 704.921156ms):
Trace[999981084]: [681.879421ms] [517.404074ms] About to write a response
2019-05-02 12:35:09.706738 W | etcdserver: apply entries took too long [330.468894ms for 1 entries]
2019-05-02 12:35:09.709777 W | etcdserver: avoid queries with large range/delete range!
2019-05-02 12:35:10.265190 W | etcdserver: apply entries took too long [443.163764ms for 1 entries]
2019-05-02 12:35:10.265260 W | etcdserver: avoid queries with large range/delete range!
I0502 12:35:10.365530       6 trace.go:76] Trace[1924322950]: "GuaranteedUpdate etcd3: *core.Endpoints" (started: 2019-05-02 12:35:09.143987711 +0000 UTC m=+348.949667488) (total time: 1.081415118s):
Trace[1924322950]: [898.620045ms] [808.17711ms] Transaction committed
Trace[1924322950]: [1.081415118s] [182.795073ms] END
I0502 12:35:10.366403       6 trace.go:76] Trace[1092698666]: "Update /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:35:09.066767795 +0000 UTC m=+348.872448072) (total time: 1.299569445s):
Trace[1092698666]: [1.299236345s] [1.235414149s] Object stored in database
I0502 12:35:10.367237       6 trace.go:76] Trace[1724272058]: "GuaranteedUpdate etcd3: *core.ConfigMap" (started: 2019-05-02 12:35:09.144949612 +0000 UTC m=+348.950629689) (total time: 1.22223483s):
Trace[1724272058]: [1.222051729s] [1.12942169s] Transaction committed
I0502 12:35:10.367527       6 trace.go:76] Trace[209556531]: "Update /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:35:09.066614995 +0000 UTC m=+348.872294272) (total time: 1.300868647s):
Trace[209556531]: [1.300667547s] [1.240385357s] Object stored in database
I0502 12:35:11.331300       6 trace.go:76] Trace[842726899]: "Get /api/v1/namespaces/default" (started: 2019-05-02 12:35:10.350041516 +0000 UTC m=+350.155721493) (total time: 977.166962ms):
Trace[842726899]: [974.508258ms] [974.488858ms] About to write a response
I0502 12:35:35.141236       6 trace.go:76] Trace[1085038790]: "Get /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:35:34.539153719 +0000 UTC m=+374.344836696) (total time: 524.029284ms):
Trace[1085038790]: [518.333576ms] [518.054976ms] About to write a response
[tiller] 2019/05/02 12:35:45 rendering rancher-monitoring chart using values
2019/05/02 12:35:45 info: manifest "rancher-monitoring/templates/metrics-service.yaml" is empty. Skipping.
2019/05/02 12:35:45 info: manifest "rancher-monitoring/templates/rbac.yaml" is empty. Skipping.
2019-05-02 12:35:45.639852 W | etcdserver: apply entries took too long [256.017983ms for 1 entries]
2019-05-02 12:35:45.642692 W | etcdserver: avoid queries with large range/delete range!
2019/05/02 12:35:45 info: manifest "rancher-monitoring/templates/deployment.yaml" is empty. Skipping.
2019/05/02 12:35:45 info: manifest "rancher-monitoring/templates/servicemonitor.yaml" is empty. Skipping.
2019/05/02 12:35:45 info: manifest "rancher-monitoring/charts/grafana/templates/rbac.yaml" is empty. Skipping.
[tiller] 2019/05/02 12:35:46 creating updated release for cluster-monitoring
[storage] 2019/05/02 12:35:46 creating release "cluster-monitoring.v2151"
[tiller] 2019/05/02 12:35:47 performing update for cluster-monitoring
[tiller] 2019/05/02 12:35:47 executing 0 pre-upgrade hooks for cluster-monitoring
[tiller] 2019/05/02 12:35:47 hooks complete for pre-upgrade cluster-monitoring
[kube] 2019/05/02 12:35:47 building resources from updated manifest
[kube] 2019/05/02 12:35:47 checking 45 resources for changes
[kube] 2019/05/02 12:35:47 Looks like there are no changes for Secret "prometheus-cluster-monitoring-additional-scrape-configs"
[kube] 2019/05/02 12:35:48 Looks like there are no changes for Secret "prometheus-cluster-monitoring-additional-alertmanager-configs"
[kube] 2019/05/02 12:35:50 Looks like there are no changes for ConfigMap "grafana-cluster-monitoring-dashboards"
[kube] 2019/05/02 12:35:50 Looks like there are no changes for ConfigMap "grafana-cluster-monitoring-nginx"
[kube] 2019/05/02 12:35:51 Looks like there are no changes for ConfigMap "grafana-cluster-monitoring-provisionings"
[kube] 2019/05/02 12:35:51 Looks like there are no changes for ConfigMap "prometheus-cluster-monitoring-nginx"
[kube] 2019/05/02 12:35:51 Looks like there are no changes for PersistentVolumeClaim "grafana-cluster-monitoring"
[kube] 2019/05/02 12:35:52 Looks like there are no changes for ServiceAccount "exporter-kube-state-cluster-monitoring"
[kube] 2019/05/02 12:35:52 Looks like there are no changes for ServiceAccount "exporter-node-cluster-monitoring"
[kube] 2019/05/02 12:35:53 Looks like there are no changes for ServiceAccount "cluster-monitoring"
I0502 12:35:54.754151       6 trace.go:76] Trace[1816935957]: "Update /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:35:54.087286572 +0000 UTC m=+393.892969649) (total time: 536.721403ms):
Trace[1816935957]: [472.985508ms] [469.552603ms] Object stored in database
2019-05-02 12:35:54.796815 W | etcdserver: apply entries took too long [120.14968ms for 1 entries]
2019-05-02 12:35:54.796864 W | etcdserver: avoid queries with large range/delete range!
I0502 12:35:55.052895       6 trace.go:76] Trace[1322689897]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:35:53.957728978 +0000 UTC m=+393.763407055) (total time: 1.095075639s):
Trace[1322689897]: [1.021682329s] [964.783743ms] About to write a response
[kube] 2019/05/02 12:35:55 Looks like there are no changes for ClusterRole "exporter-kube-state-cluster-monitoring"
I0502 12:35:57.849154       6 trace.go:76] Trace[1245451139]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:35:56.540114743 +0000 UTC m=+396.345793420) (total time: 1.308965558s):
Trace[1245451139]: [1.179745265s] [1.051463173s] About to write a response
[kube] 2019/05/02 12:35:58 Looks like there are no changes for ClusterRole "exporter-node-cluster-monitoring"
[kube] 2019/05/02 12:35:58 Looks like there are no changes for ClusterRole "prometheus-cluster-monitoring-cattle-prometheus"
[kube] 2019/05/02 12:35:59 Looks like there are no changes for ClusterRoleBinding "exporter-kube-state-cluster-monitoring"
[kube] 2019/05/02 12:35:59 Looks like there are no changes for ClusterRoleBinding "exporter-node-cluster-monitoring"
[kube] 2019/05/02 12:35:59 Looks like there are no changes for ClusterRoleBinding "prometheus-cluster-monitoring-cattle-prometheus"
2019-05-02 12:36:00.978950 W | etcdserver: apply entries took too long [524.338685ms for 1 entries]
2019-05-02 12:36:00.978996 W | etcdserver: avoid queries with large range/delete range!
[kube] 2019/05/02 12:36:01 Looks like there are no changes for Service "expose-kube-cm-metrics"
[kube] 2019/05/02 12:36:02 Looks like there are no changes for Service "expose-kube-etcd-metrics"
[kube] 2019/05/02 12:36:02 Looks like there are no changes for Service "expose-kube-scheduler-metrics"
[kube] 2019/05/02 12:36:03 Looks like there are no changes for Service "expose-kubernetes-metrics"
[kube] 2019/05/02 12:36:03 Looks like there are no changes for Service "expose-node-metrics"
[kube] 2019/05/02 12:36:04 Looks like there are no changes for Service "expose-grafana-metrics"
[kube] 2019/05/02 12:36:04 Looks like there are no changes for Service "access-grafana"
[kube] 2019/05/02 12:36:05 Looks like there are no changes for Service "expose-prometheus-metrics"
[kube] 2019/05/02 12:36:05 Looks like there are no changes for Service "access-prometheus"
[kube] 2019/05/02 12:36:05 Looks like there are no changes for DaemonSet "exporter-node-cluster-monitoring"
[kube] 2019/05/02 12:36:05 Looks like there are no changes for Deployment "exporter-kube-state-cluster-monitoring"
[kube] 2019/05/02 12:36:06 Looks like there are no changes for Deployment "grafana-cluster-monitoring"
[kube] 2019/05/02 12:36:06 Looks like there are no changes for Endpoints "expose-kube-cm-metrics"
[kube] 2019/05/02 12:36:07 Looks like there are no changes for Endpoints "expose-kube-scheduler-metrics"
[kube] 2019/05/02 12:36:07 Looks like there are no changes for Prometheus "cluster-monitoring"
[kube] 2019/05/02 12:36:07 Looks like there are no changes for PrometheusRule "exporter-kube-scheduler-cluster-monitoring"
[kube] 2019/05/02 12:36:07 Looks like there are no changes for PrometheusRule "exporter-kubernetes-cluster-monitoring"
[kube] 2019/05/02 12:36:08 Looks like there are no changes for PrometheusRule "exporter-node-cluster-monitoring"
[kube] 2019/05/02 12:36:08 Looks like there are no changes for ServiceMonitor "exporter-fluentd-cluster-monitoring"
[kube] 2019/05/02 12:36:08 Looks like there are no changes for ServiceMonitor "exporter-kube-controller-manager-cluster-monitoring"
[kube] 2019/05/02 12:36:08 Looks like there are no changes for ServiceMonitor "exporter-kube-scheduler-cluster-monitoring"
[kube] 2019/05/02 12:36:09 Looks like there are no changes for ServiceMonitor "exporter-kube-state-cluster-monitoring"
[kube] 2019/05/02 12:36:09 Looks like there are no changes for ServiceMonitor "exporter-kubelets-cluster-monitoring"
[kube] 2019/05/02 12:36:09 Looks like there are no changes for ServiceMonitor "exporter-kubernetes-cluster-monitoring"
[kube] 2019/05/02 12:36:09 Looks like there are no changes for ServiceMonitor "exporter-node-cluster-monitoring"
2019-05-02 12:36:11.087649 W | etcdserver: apply entries took too long [255.054882ms for 1 entries]
2019-05-02 12:36:11.087760 W | etcdserver: avoid queries with large range/delete range!
I0502 12:36:13.540290       6 trace.go:76] Trace[998317708]: "List /apis/batch/v1/jobs" (started: 2019-05-02 12:36:11.265347876 +0000 UTC m=+411.071028853) (total time: 2.274783903s):
Trace[998317708]: [2.274543103s] [2.274524303s] Listing from storage done
I0502 12:36:13.636303       6 trace.go:76] Trace[714306574]: "Get /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:36:10.611340097 +0000 UTC m=+410.417025374) (total time: 3.024863826s):
Trace[714306574]: [3.023739524s] [2.981793561s] About to write a response
I0502 12:36:13.663983       6 trace.go:76] Trace[1488463856]: "Get /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:36:11.237425734 +0000 UTC m=+411.043105011) (total time: 2.426462531s):
Trace[1488463856]: [2.423544226s] [2.423420026s] About to write a response
I0502 12:36:13.814720       6 trace.go:76] Trace[1710684550]: "List /api/v1/nodes" (started: 2019-05-02 12:36:13.195849664 +0000 UTC m=+413.001534941) (total time: 618.811126ms):
Trace[1710684550]: [527.074889ms] [527.040989ms] Listing from storage done
2019-05-02 12:36:15.013718 W | etcdserver: apply entries took too long [874.423208ms for 1 entries]
2019-05-02 12:36:15.014455 W | etcdserver: avoid queries with large range/delete range!
I0502 12:36:15.034090       6 trace.go:76] Trace[87873255]: "GuaranteedUpdate etcd3: *core.Endpoints" (started: 2019-05-02 12:36:14.020251798 +0000 UTC m=+413.825937475) (total time: 1.013777217s):
Trace[87873255]: [1.013607016s] [953.940527ms] Transaction committed
I0502 12:36:15.034747       6 trace.go:76] Trace[886827659]: "Update /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:36:13.87457748 +0000 UTC m=+413.680255157) (total time: 1.159748835s):
Trace[886827659]: [1.159573735s] [1.101642749s] Object stored in database
2019-05-02 12:36:15.166229 W | etcdserver: apply entries took too long [151.702427ms for 1 entries]
2019-05-02 12:36:15.176109 W | etcdserver: avoid queries with large range/delete range!
I0502 12:36:15.266880       6 trace.go:76] Trace[1573627939]: "GuaranteedUpdate etcd3: *core.ConfigMap" (started: 2019-05-02 12:36:14.075586781 +0000 UTC m=+413.881264258) (total time: 1.189276679s):
Trace[1573627939]: [1.17634186s] [1.173612656s] Transaction committed
I0502 12:36:15.342717       6 trace.go:76] Trace[317205404]: "Update /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:36:14.026507307 +0000 UTC m=+413.832192884) (total time: 1.240698256s):
Trace[317205404]: [1.240421356s] [1.232373944s] Object stored in database
I0502 12:36:15.631714       6 trace.go:76] Trace[1318689638]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:36:11.496155121 +0000 UTC m=+411.301836098) (total time: 4.133583785s):
Trace[1318689638]: [3.975911349s] [3.975764249s] About to write a response
[kube] 2019/05/02 12:36:16 Looks like there are no changes for ServiceMonitor "grafana-cluster-monitoring"
I0502 12:36:17.116550       6 trace.go:76] Trace[133531972]: "Get /api/v1/namespaces/default" (started: 2019-05-02 12:36:16.027424101 +0000 UTC m=+415.833109678) (total time: 1.088996029s):
Trace[133531972]: [1.088745629s] [1.087600627s] About to write a response
2019-05-02 12:36:18.770343 W | etcdserver: apply entries took too long [156.701835ms for 1 entries]
2019-05-02 12:36:18.770418 W | etcdserver: avoid queries with large range/delete range!
2019-05-02 12:36:20.105068 W | etcdserver: apply entries took too long [782.09627ms for 1 entries]
2019-05-02 12:36:20.105261 W | etcdserver: avoid queries with large range/delete range!
I0502 12:36:20.131518       6 trace.go:76] Trace[552466000]: "GuaranteedUpdate etcd3: *core.Endpoints" (started: 2019-05-02 12:36:18.110900618 +0000 UTC m=+417.916585995) (total time: 1.998022589s):
Trace[552466000]: [418.066526ms] [418.066526ms] initial value restored
Trace[552466000]: [1.997914789s] [1.57775636s] Transaction committed
I0502 12:36:20.132838       6 trace.go:76] Trace[843006566]: "Update /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-05-02 12:36:18.109459316 +0000 UTC m=+417.915144593) (total time: 2.023285527s):
Trace[843006566]: [2.022204225s] [2.021761724s] Object stored in database
I0502 12:36:20.151601       6 trace.go:76] Trace[1990736941]: "GuaranteedUpdate etcd3: *core.Endpoints" (started: 2019-05-02 12:36:17.541201466 +0000 UTC m=+417.346887543) (total time: 2.610275105s):
Trace[1990736941]: [393.783989ms] [393.783989ms] initial value restored
Trace[1990736941]: [1.676912109s] [1.28312812s] Transaction prepared
Trace[1990736941]: [2.610017105s] [933.104996ms] Transaction committed
I0502 12:36:20.168575       6 trace.go:76] Trace[1216243324]: "GuaranteedUpdate etcd3: *core.ConfigMap" (started: 2019-05-02 12:36:19.437285703 +0000 UTC m=+419.242971180) (total time: 729.953592ms):
Trace[1216243324]: [727.483588ms] [725.545586ms] Transaction committed
I0502 12:36:20.210958       6 trace.go:76] Trace[752902646]: "Update /api/v1/namespaces/kube-system/configmaps/cattle-controllers" (started: 2019-05-02 12:36:19.391714734 +0000 UTC m=+419.197392811) (total time: 818.107324ms):
Trace[752902646]: [777.008563ms] [776.772762ms] Object stored in database
I0502 12:36:20.499649       6 trace.go:76] Trace[301300681]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:36:19.476764362 +0000 UTC m=+419.282526139) (total time: 1.02270943s):
Trace[301300681]: [825.505935ms] [825.379235ms] About to write a response
Trace[301300681]: [1.02270943s] [197.203495ms] END
I0502 12:36:20.551690       6 trace.go:76] Trace[1520707606]: "Get /apis/management.cattle.io/v3/clusters/c-dx942" (started: 2019-05-02 12:36:19.359289586 +0000 UTC m=+419.164970663) (total time: 1.192315184s):
Trace[1520707606]: [1.152026023s] [1.151875723s] About to write a response
[kube] 2019/05/02 12:36:21 Looks like there are no changes for ServiceMonitor "prometheus-cluster-monitoring"
2019-05-02 12:36:21.348268 W | etcdserver: apply entries took too long [153.826331ms for 1 entries]
2019-05-02 12:36:21.348858 W | etcdserver: avoid queries with large range/delete range!
[tiller] 2019/05/02 12:36:22 executing 0 post-upgrade hooks for cluster-monitoring
[tiller] 2019/05/02 12:36:22 hooks complete for post-upgrade cluster-monitoring
[storage] 2019/05/02 12:36:22 updating release "cluster-monitoring.v2150"

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.2.2
Installation option (single install/HA): single install

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory):  5x VM, 6 CPUs, 12 GiB
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.9", GitCommit:"16236ce91790d4c75b79f6ce96841db1c843e7d2", GitTreeState:"clean", BuildDate:"2019-03-25T06:30:48Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Version:           18.09.5
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        e8ff056dbc
 Built:             Thu Apr 11 04:44:28 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.4
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       d14af54
  Built:            Wed Mar 27 18:01:48 2019
  OS/Arch:          linux/amd64
  Experimental:     false

We have simular issues with other apps (https://github.com/getsentry/sentry/). The deployment takes a long time and then it seems like a timelimit hit (after 5 minutes), and it starts to redeploy the whole app (I never noticed this on previous version).

We have also experienced the same issue, here's a screenshot of the ConfigMaps resulted from redeploying:

Fresh Rancher 2.2.2 install
Kubernetes 1.13.5
Docker 18.09.5

Encountered this on a 2.2.2 environment. This is bad, because it will very quickly cause the environment to become non-functional for the system project for that specific cluster.

Got the bug reproduced on v2.2.2
Steps:

add a cluster with 3 etcd nodes, 2 control plane nodes and any number of worker nodes
enable the cluster monitoring

Result:

right after enabling the cluster monitoring, the app cluster-monitoring is deployed 6 times.

The bug fix is validated on Rancher: master 5d74988c
Steps:

add a cluster with 3 etcd nodes, 2 control plane nodes and any number of worker nodes
enable the cluster monitoring
enable the project monitoring

Result:

notice that the app cluster-monitoring and project-monitoring are deployed only one time.

The issue is not fixed because the app cluster-monitoring still get redeployed several times when the cluster monitoring is enabled.
We also see that whenever we deploy apps and workloads, the cluster-monitoring also get re-deployed.

fixed in master

The bug fix is validated on Rancher: master beffccd
Steps:

add several different kinds of clusters, in my case they are EC2 cluster, custom RKE cluster, imported GKE cluster
enable the cluster monitoring
deploy some workloads and apps
run automation tests on the cluster
leave the cluster idle for a while

Result:

notice that the app cluster-monitoring and project-monitoring are deployed only one time.

Will this fix be released in version 2.2.x or we will wait for this until 2.3.x? As we are currently unable to deploy monitoring to our cluster.

@manarhusrieh this has been resolved for us, we're on 2.2.4 but i believe since 2.2.2

@spencergilbert We are currently running 2.2.2 and the problem exists. We will apply the patch 2.2.5 once released.

Just to confirm the problem is resolved on patch 2.2.5.

authors: Oats87 XzenTorXz cjellick happydenn jiaqiluo manarhusrieh moschlar spencergilbert


text:
rancher 2.3.0 monitoring api not ready

hi
I'm using 2.3.0 rancher monitoring , but facing this , monitoring suddenly stop, in rancher UI , display "Monitoring API is not ready"
then , i saw pod has unusual status.
”prometheus-cluster-monitoring-0                            3/5     CrashLoopBackOff   15         23m“
describe pod log is ：
Normal   Pulled                  14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Container image "rancher/nginx:1.17.4-alpine" already present on machine
  Normal   Created                 14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Created container prometheus-proxy
  Normal   Started                 14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Started container prometheus-proxy
  Normal   Created                 14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Created container rules-configmap-reloader
  Normal   Started                 14m (x2 over 15m)    kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Started container prometheus
  Normal   Created                 14m (x2 over 15m)    kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Created container prometheus
  Normal   Pulled                  14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Container image "rancher/prom-prometheus:v2.11.1" already present on machine
  Warning  Unhealthy               14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Readiness probe failed: HTTP probe failed with statuscode: 503
  Warning  BackOff                 14m                  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Back-off restarting failed container
  Warning  Unhealthy               13m (x2 over 14m)    kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Readiness probe failed: HTTP probe failed with statuscode: 502
  Warning  Unhealthy               4m6s (x50 over 13m)  kubelet, ip-10-18-255-93.cn-northwest-1.compute.internal  Liveness probe failed: HTTP probe failed with statuscode: 502

Maybe because that resource limit not enough , I am trying to upgrade this .

reslove it by upgrade memory limit , close it


text:
Opening system project in GUI causes massive network traffic

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):
Set up Rancher HA on RKE Cluster behind Loadbalancer
Deploy cluster
Open System project
Result:
Opening the project on the GUI causes a massive network spike lasting a few minutes, coming from the rancher-cluster-agent pod, to the loadbalancer, and then to the Rancher HA cluster.
Other details that may be helpful:
This only happens in one of our clusters, for some reason. Besides triggering it manually it also occurs every 30 minutes,
I have tried looking around in the logfiles on the node that hosts the pod, as well as the pod itself. There is absolutely nothing that would point to it causing such high traffic.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.2.8
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): vSphere
Machine type (cloud/VM/metal) and specifications (CPU/memory): VM
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.9", GitCommit:"3e4f6a92de5f259ef313ad876bb008897f6a98f0", GitTreeState:"clean", BuildDate:"2019-08-05T09:22:00Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:16Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Version:           18.06.3-ce
 API version:       1.38
 Go version:        go1.10.4
 Git commit:        d7080c1
 Built:             Wed Feb 20 02:24:22 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.3-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       d7080c1
  Built:            Wed Feb 20 02:25:33 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Alright, we have figured out the solution to the issue, but now it's really more of an enhancement.
The issue was caused by a large number of configmaps in the kube-system namespace. We did not set a limit on our helm revisions, and one of our developers deployed quite a bit and quite a lot. Every deployment created a 400kb configmap - and we had over 700 of them at one point.
We have solved this issue by simply limiting the max-history with helm, but this really causes another question: when opening a project, is Rancher actually loading every single configmap/deployment/etc. to present to the user as opposed to when requesting it?
We only noticed this issue because Rancher is running behind an F5 Loadbalancer with a license maximum of 200mbit/s. It still caused a lot of traffic, and I don't think this is good/intended behavior.  Cluster resources in a project should really only be loaded if a user actually requests them by interacting with it.

I think it's the same problem as https://github.com/rancher/rancher/issues/21587.

authors: ThunderRush fabiorauber


text:
Can't provision RKE clusters due to Rkeaddons.management.cattle.io "nginxingress-v1.15.12" not found error

What kind of request is this:
Bug
Steps to reproduce (least amount of steps as possible):

Install Rancher master-3004-head and v2.4-3003-head
Deploy a RKE DO cluster

Result:
Provisioning will fail with
[ERROR] getAddonTemplates: k8sVersion v1.17.6-rancher1-1 addon nginxingress-v1.15.12 [rkeaddons.management.cattle.io "nginxingress-v1.15.12" not found]

Other details that may be helpful:
Environment information

Rancher version: master-3004-head and v2.4-3003-head (05/21/2020)
Installation option (single install/HA): single

Validated this is no longer an issue in

v2.4-head (05/22/2020) commit 899dce29e I used letsencrypt method to workaround #27198
master-head (05/22/2020) commit 7f82086e0


text:
Release v2.3.8 Registry Credentials Google container Registry json file not accepting in password field

What kind of request is this (question/bug/enhancement/feature request): BUG
Steps to reproduce (least amount of steps as possible):
Registry Credentials while adding Google Cloud Registry password of the json file its keep spinning.
Without empty password its was working.
After I upgrade from 2.3.7 to 2.3.8 this is not working
Before that I could able to add GCP registery.
Result:
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):v2.3.8
Installation option (single install/HA):single

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory): cloud GCP instances
Kubernetes version (use kubectl version): v1.17.5

(paste the output here)

Docker version (use docker version): Docker version 19.03.11, build 42e35e61f3

(paste the output here)

any update on this issue.


text:
old container show up as unavailable Node when upgrading using docker install

Steps:

Create a vm
Install rancher using docker
Log into Rancher and go to local nodes (which always seems to be here now, even if I don't use the flag?)
Go back to terminal and rm the docker container and upgrade to new master
Log into Rancher and go to Nodes

Results: Container I removed is still showing up as a node and now my local cluster thinks it's broken cause it can't find the old node.
ember:

vue:

Comment:  The container is also still showing up in all the node drop-downs for workloads.

Reproduced the issue on master-head - commit id: ec04f7878

On a single node install -- docker run -v /home/ubuntu/state:/var/lib/rancher -d -p 80:80 -p 443:443 --restart=unless-stopped --privileged rancher/rancher:master-head
Rancher deploys. Local cluster is deployed. looks fine.
In the VM, stop and delete the above container.
Run a new docker run command ^^^ on this VM

VUE UI:

Unavailable node shows up in scheduling while deploying a workload:

Workaround is just deleting old node by hand, so moving to 2.5.1. Ideally we can handle there automatically, which might be somewhat tricky. We could also allow to delete in UI but thats still annoying.

I'm going to just fix the node name to "local-node" so this doesn't happen.  You won't get a terminated node.

@cbron This has to be fixed because this means that the pods for fleet, webhook and stuff are not running anymore.

On master-head - commit id: eb96d76c

Bring up docker in single node install - docker run -d --privileged --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:master-head
The local cluster is seen as:

Stop the rancher server

docker stop <>
docker create --volumes-from 80d995 --name rancher-data2 rancher/rancher:master-head
docker run -d --privileged --volumes-from rancher-data2 --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:master-head

The local cluster is seen as above ^^^

authors: cbron ibuildthecloud sowmyav27 tfiduccia


text:
[Forwardport] git-remote-http defunct processes from cluster-register_cattle-cluster-agent

Forwardport of https://github.com/rancher/rancher/issues/30172

Master: PR https://github.com/rancher/rancher/pull/31847

Blocked on rancher/rancher#31964