Has anyone had success using LXD on Fedora 31? I have been using it on another machine with Fedora 30 just fine, but after installing Fedora 31 on a new laptop, the containers don't get an IPv4 address:
$ lxc list
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
+-------+---------+------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| c1 | RUNNING | | | PERSISTENT | 0 |
+-------+---------+------+------+------------+-----------+
Attempting something like ping inside the container gives the error:
connect: Network is unreachable
Nothing works that needs the network, but otherwise the containers seem fine and the network is fine on the host laptop.
The one notable difference I see is the warning on Fedora 31:
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
The version of LXD is 3.18 on both machines (installed using snap), and I've compared with both environments but couldn't see any glaring differences that would point to a problem other the cgroup warning.
This is what the network bridge looks like:
$ lxc network show lxdbr0
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
config:
ipv4.address: 10.192.103.1/24
ipv4.nat: "true"
ipv6.address: none
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/c1
managed: true
status: Created
locations:
- none
Any ideas on where to start looking?
According to the official documentation:
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
I found the fix to the problem. Turns out that cgroup v2 warning was more than just a warning. If cgroup v2 is disabled, it works as expected.
To disable cgroup v2, add the following to the linux boot line:
systemd.unified_cgroup_hierarchy=0
There may be other ways to fix it, but this works for now.
Related
Trying to fetch config block to create a config update.
I'm using the test network in fabric samples with default settings (no CA)
even after starting the network I cannot fetch any blocks. not latest or oldest either
This is the output I'm getting
peer channel fetch config
2022-02-08 11:09:47.306 +03 [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2022-02-08 11:09:47.309 +03 [cli.common] readBlock -> INFO 002 Expect block, but got status: &{NOT_FOUND}
Error: can't read the block: &{NOT_FOUND}
I think you need to specify the channel, for example:
peer channel fetch config -c mychannel
That works for me with the default test network channel, and I get the same error you saw without the -c option.
It's also worth having a look at the test network scripts since they are meant to be a sample themselves. In this case configUpdate.sh does a config update.
I'm trying to set up a Kubernetes cluster on GCE using CoreOS as the base OS. But I'm having the following issue when trying to make the cluster a multizone cluster by setting the --cloud-provider and --cloud-config flags.
The below is the output from the API Server on the master node:
Jun 15 09:22:09 cos-000-pub-pvt-master.c.project-id.internal kubelet-wrapper[1098]: E0615 09:22:09.790068 1098 gce.go:2380] Failed to retrieve instance: "10.0.0.2"
Jun 15 09:22:09 cos-000-pub-pvt-master.c.project-id.internal kubelet-wrapper[1098]: E0615 09:22:09.790125 1098 gce.go:2414] getInstanceByName/multiple-zones: failed to get instance 10.0.0.2; err: instance not found
Jun 15 09:22:09 cos-000-pub-pvt-master.c.project-id.internal kubelet-wrapper[1098]: E0615 09:22:09.790151 1098 kubelet.go:1131] Unable to construct api.Node object for kubelet: failed to get external ID from cloud provider: instance not found
When running kubectl get nodes there is no output, but when running kubectl --namespace kube-system get pods I see the API Server, Controller Manager, Scheduler and each of the Proxies for each of the nodes. Although I can see them they are restarted every 45-60 seconds.
The GCE config file is as follows:
[GLOBAL]
multizone=true
If I've left something out that can help let me know.
It seems that the --hostname-override flag was causing this issue. I've removed that and the master is now able to find the node in the GCE API.
I'm attempting to configure HAProxy to serve an RSA or ECC certificate depending on the client's browser. I initially am trying to get ECC certificates configured, and I noticed that the latest version of Chrome does not support them. Wondering if anyone else is having this problem? I am using OS X 10.11.4 with the following versions:
Chrome (50.0.2661.94) (64-bit) [doesn't work]
Firefox (46.0) (64-bit) [works]
Safari (9.1 11601.5.17.1) (64-bit) [works]
cURL (7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5) [works]
The cURL command I call via curl --ciphers ecdhe_ecdsa_aes_128_sha --ssl --head --tlsv1.2 https://<url> and it returns 200 OK.
And I am using Ubuntu Xenial 16.04 LTS on the server side with the following versions:
[root#haproxy-server]: /etc/haproxy # haproxy -vv
HA-Proxy version 1.6.4 2016/03/13
Copyright 2000-2016 Willy Tarreau <willy#haproxy.org>
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
OPTIONS = USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g-fips 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.38 2015-11-23
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Here's the screenshot of the exact problem: http://imgur.com/wlmQbIi
Here's the screenshot of the same website with Safari: http://imgur.com/FEwmmj9
And finally, my haproxy.cfg file:
global
log /dev/log local0
log /dev/log local1 notice
user haproxy
group haproxy
chroot /var/lib/haproxy
daemon
stats socket /run/haproxy/admin.sock level admin
maxconn 15000
spread-checks 5
tune.ssl.default-dh-param 2048
tune.ssl.maxrecord 1400
tune.idletimer 1000
ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
defaults
log global
mode http
retries 3
balance roundrobin
hash-type map-based
option httplog
option dontlognull
option forwardfor
option http-server-close
option redispatch
option abortonclose
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 30s
timeout http-keep-alive 10s
timeout check 10s
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http-frontend
bind *:80 accept-proxy
reqadd X-Forwarded-Proto:\ http
use_backend %[req.hdr(host),lower,map_sub(/etc/haproxy/backend.map,test-backend)]
frontend https-frontend
bind *:443 accept-proxy ssl crt /etc/ssl/pem/ecc alpn http/1.1
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r\ ssl_version:%sslv\ ssl_cipher:%sslc\ %[ssl_fc_sni]\ %[ssl_fc_npn]
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubdomains;\ preload
rspadd X-Frame-Options:\ DENY
reqadd X-Forwarded-Proto:\ https
use_backend %[req.hdr(host),lower,map_sub(/etc/haproxy/backend.map,test-backend)]
backend test-backend
balance leastconn
redirect scheme https code 301 if !{ ssl_fc }
server test-server 10.10.10.40:80 check
I know this post is not in the right seciton of StackExchange (sorry!) but I wanted to post a potential solution. I think the problem is the elliptic curves support in Chrome vs. Firefox vs. Safari. From the SSLLabs website:
Safari 9 / OS X 10.11: secp256r1, secp384r1, secp521r1
Firefox 44 / OS X: secp256r1, secp384r1, secp521r1
Chrome 48 / OS X: secp256r1, secp384r1
The problem is the private key for the ECC certificate I was testing was generated with secp521r1 (http://imgur.com/dbrJQuW), which the latest version of Chrome on OS X 10.11 doesn't support.
See this issue: https://security.stackexchange.com/questions/100991/why-is-secp521r1-no-longer-supported-in-chrome-others
It seems that only the following two cipher suite are supported by your web server:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
I suppose that missing some cipher suite (at least TLS_RSA_WITH_AES_128_CBC_SHA) is the reason of your problem.
The cipher suite TLS_RSA_WITH_AES_128_CBC_SHA must be supported in TLS 1.2 (see the section 9 Mandatory Cipher Suites or RFC5246). In the same way I would you recommend to see forward and to include protocols
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
and the suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
are strictly recommended too. See TLS 1.3 specification. You use Nginx web server, which should support TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, which are very good because of combination the security and the performance. I'd recommend you to include all the Cipher Suites.
I'd recommend you additionally to use or at least to examine carefully the recommendation of Nginx setting for modern or intermediate web browsers by Mozilla SSL Configuration Generator. You can read more about the suites here.
How to create FiWare instance and connect it to internet?
I like the idea and I have big plans on using this infrastructure, but...
I've trying to create instance and make ssh connection to it for some time now.
Created key-pair
Created security group (22,3306,1)
Created instance ubuntu 14 (also tried others)
Also tried ubuntu 12, POI and others already
Added node-int-net-01 and node-int-noinet-net-02 to it when creating
Also tried already with 1 network only
Allocated floating IP
Associated it with the local IP that came from "node-int-net-01"
Statuses:
Instance: ACTIVE, Power State RUNNING
"node-int-net-01" networks in list: shared-subnet 192.168.192.0/18 Yes ACTIVE UP
Inside "node-int-net-01":
Network: Admin State: DOWN, Shared: No, External Network: No
Subnet: DHCP and all ok
Ports: Status: BUILD, Admin State: UP
The confusing parts are (for clue, don't have to answer those if we have solution):
How can network be EXTERNAL-SHARED-ACTIVE-UP and DOWN-NOT_SHARED-NO_EXTERNAL at the same time - perhaps there's an error
What means Port status: BUILD, i mean it must have been building the port like 3 days already. Should i build there something, is it an order or status? Perhaps it means BUILT or BUILDING instead.
What means instance ACTIVE? Is it still active (busy) and i should wait? Or it can be actively used already? From VM Display I never saw it going to unix prompt>, is it kind of fiware itself using this telnet instance? I rather saw things like
"request error",
"connection timeout",
"socket.error",
"Error 101 Network is unreachable".
"cloud-init-nonet [13:31]: waiting 120 seconds for network device"
numerous black-screens and never ending Booting from hard-disk
from Instance log saw endless: "Waiting for network configuration", but that one was cured
Thou i saw "localhost login prompt, but as i only created PEM, then
cant imagine what to do with it - where do i get root/pwd? But i guess it was some error that it ended up there.
The latest status from Instance\Log is:
cloud-init-nonet[4.52]: static networking is now up
* Starting configure network device[74G[ OK ]
* Starting Mount network filesystems[74G[ OK ]
* Stopping Mount network filesystems[74G[ OK ]
* Stopping cold plug devices[74G[ OK ]
* Stopping log initial device creation[74G[ OK ]
* Starting enable remaining boot-time encrypted block devices[74G[ OK ]
Cloud-init v. 0.7.5 running 'init' at Sat, 16 Apr 2016 01:23:11 +0000. Up 5.07 seconds.
ci-info: ++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++
ci-info: +--------+------+-----------------+---------------+-------------------+
ci-info: | Device | Up | Address | Mask | Hw-Address |
ci-info: +--------+------+-----------------+---------------+-------------------+
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . |
ci-info: | eth0 | True | 192.168.242.127 | 255.255.192.0 | fa:16:3e:7a:47:94 |
ci-info: +--------+------+-----------------+---------------+-------------------+
ci-info: +++++++++++++++++++++++++++++++++Route info++++++++++++++++++++++++++++++++++
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: | 0 | 0.0.0.0 | 192.168.192.1 | 0.0.0.0 | eth0 | UG |
ci-info: | 1 | 192.168.192.0 | 0.0.0.0 | 255.255.192.0 | eth0 | U |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
For a ping and ssh i get: "Destination Host Unreachable" and "No route to host"
Also tried allocating floating IP with "federation" pool, but with that IP i just got time-outs for ping and ssh
I read already:
wiki
fiware help
stackoverflow
Followed also the steps in this slideshow http://www.slideshare.net/fermingalan/developing-your-first-application-using-fi-ware-20130903
http://cosmos.lab.fi-ware.org/cosmos-gui/ seems to be down
EDIT: can use this one (need to use https and accept bad cert)
http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Data.BigData_R4#Basic_concepts
http://catalogue.fiware.org/enablers/bigdata-analysis-cosmos/documentation - no info about it neither.
Any ideas? Perhaps there is an UI (other than the web page at https://cloud.lab.fiware.org/ that seems to be in early beta) for using FiWare (that can do all the "anyway-mandatory" steps for users (developers)?
Maybe the problem is that I'm a software developer not network administrator, and perhaps this interface is meant for linux network andministrators.
The message "Error 101 Network is unreachable" shows that there was a problem in the VM network. node-int-net-01 is the shared network to be joined with the public network, while node-int-noinet-net-02 is to be joined with a network to use VPN. You shouldn't use both networks in the same VM, just you should use node-int-net-01.
The code messages like BUILD, ACTIVE and so on, are codes belonging to Openstack.
Regarding ping, you should open the icmp port in the security port to allow it.
Anyway, if you continue having problems, you can send a mail to FIWARE Lab support fiware-lab-help#lists.fiware.org, indicating your concrete data.
Given a sample script that opens /dev/tty:
# sample.rb
tty=File.open("/dev/tty", "w+")
tty.print "> "
tty.puts tty.gets.upcase
I can run it with normal jruby just fine:
% jruby sample.rb
> hello
HELLO
%
However, if I try to use /dev/tty with nailgun, then the tty is bound to the nailgun server, not the client:
# server terminal | # client terminal
% jruby --ng-server |
NGServer 0.9.1 started on all interfaces, port 2113. |
| % jruby --ng sample.rb
> hello |
HELLO |
| %
(the vertical spacing is to show timing, the actual output for each lacks the blank lines)
Is this expected behaviour, or a bug?
If it's expected behaviour, is there a way I can detect whether a script is being run with --ng so I can
avoid opening /dev/tty?
Looking at the Nailgun client/server protocol, it doesn't look like it supports what would need to happen to use the client's /dev/tty (have client open a file, read/write from client to server).
Whether it's a bug or not, it's outside the capabilities of Nailgun currently.
Detecting whether we're on a Nailgun server can be done via
# true if on a nailgun server, false elsewise
system("ps -fp #{Process.pid} | grep NGServer > /dev/null")