I have a VM scale set with this image:
Publisher: MicrosoftWindowsServer
Offer: WindowsServer
SKU: 2016-Datacenter-with-Containers
Version: latest
These machines are running SSL web endpoint hosted in service fabric. The website is build in dotnetcore with a WebListener which propably uses the http.sys
I was wondering why new VM images still supports RC4 ciphers and how to disable them. I don't want to do it manually because that will break to autoscaling.
Similar issue, but then for Worker roles: How to disable RC4 cipher on Azure Web Roles
Treating this as two separate questions:
For the Windows 2016 virtual machine images - typically backwards compatibility is prioritized to avoid breaking existing applications which rely on older protocols. Adding the windows-server-2016 tag in case anyone wants to comment further on that.
For scale sets - Write a custom script extension to apply the same changes you'd have applied manually. This will then apply to every VM, and new VMs that are subsequently created.
Related
i m exploring GCP and i love the way it lets the developer play with such costly infrastructure. till now i have learnt a lot many things. i m no more a beginner and i have this case which i m unable to find docs or example for or i might be thinking in wrong direction.
I want to build an auto-scaling hosting solution where users can :
Create Account
Create multiple websites [these websites are basically tempaltes where user can define certain fields and the website is rendered in a specific manner | users are not allowed to upload file instead just some data entries]
In a website user can connect domain [put 'A' record DNS entry in their domain]
After that an SSl is provisioned automatically by the platform and the website is up and running. [somewhat like firebase]
I could easily create such a project on one server with the following configuration[skipped simple steps like user auth etc.]:
I use ubunutu 16.04 as my machine type with 4GB ram and 10GB persistance disk
Then i install nvm [a package to manage node.js]
after that i install specific version of node.js using nvm
i have written a simple javascript package in which i use express server to respond to the client requests with some html
for managing ssl i use letsencrypt's certbot package
i use pm2 to run the javascipt file as service in background
after being able to accomplish this thing i could see everything works the way i want it to.
then i started exploring GCP's load balancers there i learnt about the 4 layer and 7 layer LBs and i implemented some hello world tests [using startup scripts] in all possible configuration like
7 layer http
7 layer https
4 layer internal tcp
4 layer internal ssl
Here is the main problem i m facing :
I can't find a way to dynamically allocate an SSL to an incoming request to the load balancer
In my case requests might be coming from any domain so GCP load balacer must have some sort of configuration to provision SSL for specific domain [i have read that it can alloccate an SSL for upto 100 domains but how could i automate things] or could there be a way that instead of requests being proxied[LB generates a new requeest to the internal servers], requests are just being redirected so that the internal servers can handle the SSL management themseleves
I might be wrong somewhere in my understanding of the concepts. Please help me solve the problem. i want to build firebase-hosting clone at my own. anykind of response is welcomed 🙏🙏🙏
One way to do it would be to update your JS script to generate Google-managed certificate for each new domain via gcloud:
gcloud compute ssl-certificates create CERTIFICATE_NAME \
--description=DESCRIPTION \
--domains=DOMAIN_LIST \
--global
and then apply it to the load balancer:
gcloud compute target-https-proxies update TARGET_PROXY_NAME \
--ssl-certificates SSL_CERTIFICATE_LIST \
--global-ssl-certificates \
--global
Please be aware that it may take anywhere from 5 to 20 minutes for the Load Balancer to start using new certificates.
You can find more information here.
I'm looking to give Cloud Build access to a PostgreSQL database during the steps because it's part of an integration testing from the Python application I'm running. Any suggestions on how to handle this authorization without exposing the database to the world?
You can do this using a Private Pool where you define the network CIDR to be used at build time; see https://cloud.google.com/build/docs/private-pools/private-pools-overview to learn more.
(Previous answer follows, which I've left in place for transparency around history.)
At this time, you would need to whitelist all of the GCE public IP address ranges -- which effectively exposes your database to the world. (So don't do that!)
However, at Google Next we announced and demoed a coming Alpha release that will enable you to run GCB workloads in a hybrid VPC world with access to protected (on-prem) resources. As part of that Alpha, you could whitelist internal-only addresses to achieve your goal securely.
You can watch for a public announcement in our release notes.
Now you can use IAP (Identity-Aware Proxy) TCP forwarding feature.
I don't know if this is still helpful or not but I run into a similar situation a while ago and I was able fix it like this.
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: /bin/sh
args:
- '-c'
- |
gcloud compute start-iap-tunnel sql-vm 5555 \
--local-host-port=localhost:5555 \
--zone=us-west1-a & sleep 5 && python echo_client.py
I also wrote a blog post about this. Check it here hodo.dev
We have a working setup of 3 peer nodes and a multi user rest server running on 1 of the peers. Now there are multiple user cards created and imported in the rest server(using web based client) which is working fine. I can trigger transactions and query the blockchain with it.
However In case I need to upgrade my network and there is some change in model file(i.e. any participant/asset/transaction parameters changes). I need to restart rest server so that effect can be observed by WEB based client application. So my questions are:
1. Is there a way to upgrade Rest interfaces without restarting the server.
2. In case Rest server crashed or restarted is there some way to use the old cards that were created before server shutdown.
When the REST server starts you can see that it "discovers" the Business Network and then generates the End Points. The discovery is not dynamic, so that when you change the model or other element of a BNA you need to restart the REST server to re-discover the updated network. (In a live scenario I would think changes to the model are infrequent.)
Are you using multi-user mode for the REST server? Assuming that you are, then Configuring the REST server with a persistent Data Source as described in the documentation, or this tutorial should solve the problem of re-importing the cards. You could also "backup" the cards after they have been used the first time by Exporting them.
2 questions:
1) Do we need to purchase additional license to test mobile first on AWS?
Currently we are using the free eclipse version for the developer to test on their own macbook.
At the moment, we need to setup a server for business users to test. So we are thinking of leveraging AWS (EC2) to setup a MobileFirst Server. However according to this tutorial, we need to purchse MobileFiest Server:
This tutorial is intended for use with MobileFirst Server, which is available for purchase from IBM.
We have already purchase a license for the production server but not for the testing server.
2) Which AMI (Amazon Machine Image) should we choose to run MobileFirst server?
1) Do we need to purchase additional license to test mobile first on AWS?
In order to install the MobileFirst Server on an external server (anything other than Eclipse), you must buy MobileFirst Platform Foundation from IBM.
2) Which AMI (Amazon Machine Image) should we choose to run MobileFirst server?
MobileFirst supports Linux in general, so you should be able to use any of those. Most popular I assume would be Ubuntu.
You may also want to check Amazon's community where users share images, and you may find there someone who shares an image for MobileFirst.
Evolution of this question
This started as an attempt to find other recommendations for running Django on Linux, accessing SQL Server via Django-PyODBC, and supporting Unicode as competently as in installations running Django on Windows.
After failing to materialize with a good solution for ODBC drivers in Linux that would provide the same level of support for Unicode as the Windows ODBC driver; the question morphed into coping with the negative side-effect of not having an Apache daemon mode in Windows.
The question
If you run Apache+mod_wsgi on Windows, every time you deploy new Django code you are required to restart the Apache server. See Graham's answer for details on why.
How to run a dependable set of applications and services when you might be required to restart Apache, denying service until it completely restarts?
The issue
We use SQL Server 2005 and we need to support unicode characters and certain characters (like smart-quotes) generated in Microsoft Office applications.
Running Django atop SQL Server 2005 requires us to use Django-PyODBC. It works great on Windows/Linux/Mac OS X; but if you require unicode support, you are out of luck on Linux / Mac OS X - the ODBC drivers for SQL Server in Unix are in varied stage of unicode compliance. FreeTDS, the open source driver, works for some characters if you specify a client character encoding of UTF-8 (*); but doesn't support all characters.
In our tests, running Django on Windows 2003 and using the Microsoft ODBC driver allowed us to properly insert/update/select any character in several different languages, and the Microsoft smart characters from Office applications.
But running on Windows means that every time we deploy new code we are required to bounce Apache - which means a few seconds without service.
(*) The only way we managed to get to the point where some characters would be accepted with FreeTDS, frankly, was to add a client charset entry to freetds.conf:
[a_db_server]
host = a_db_server
port = 1433
tds version = 8.0
client charset = UTF-8
In relation to reloading on Windows when using Apache/mod_wsgi, read my response to:
Server software choice for Django live/staging
Might be bad form to accept one's own answer, but it suited our case and it may help others...
First and foremost: we gave up trying to find an ODBC driver that would work properly with PyODBC and support unicode as competently as the Microsoft native ODBC driver. FreeTDS works partially, and some of the commercial drivers out there just didn't cut it in our tests. We considered a ODBC-JDBC bridge, but never really tested it.
We also thought about using an ODBC router, but given the price for a multi-user solution, the potential for more complexity, and the low load scenario for our Django apps; we decided to just stick with running Django on Windows and try to cope with the requirement of restarting the Apache server every time a new version of any of the Django apps is deployed.
What we did to cope with the Apache restart and still provide service availability:
We deployed an Apache server as a proxy/load-balancer to a cluster of (at the moment) two Apache servers running on Windows
On each of the Windows Apache servers in the cluster we have all our Django apps running
When new code must be deployed to the servers we:
Disable one of the servers in the cluster via Apache's balancer-manager interface
Apply the updates and install any new Django apps in the disabled server
Test the modifications in the disabled server
Reenable the the server in the cluster via Apache's balancer-manager interface
Perform the same steps for the second server
As long as one of the servers in the cluster is enabled and running, the applications and services are available to our users - no interruption. At the same time we gained some load-balancing (in our case we really don't need it at this point).
The proxy Apache servers rewrites all the redirects and cookie response headers, so as long as people are accessing the services through the proxy, there are no modifications needed in the Django code whatsoever.