I'm trying to develop fully stand-alone server that would be able to upgrade themselves without any human intervention. To be more acute, here are the requirements :
- Every nights the server checks for updates on a specified server :
- When a upgrade is available, it downloads a new configuration file or something
- Then the server proceeds its upgrade but if anything goes wrong (internet connection is lost or something is badly downloaded) the server rolls back to its previous configuration.
In fact we don't really care if the server isn't up to date but we want to be sure that its still running (even in a old version). I've looked for configuration management system and found fancy tools like Puppet. But, for instance, if puppet can't download a new debian package, the update will failed and there's a risk that the server can't fullfil it's task.
So i was wondering, do I have to check if every packages are correctly downloaded before launching the upgrade or is there any fancy tools that can do it for me and rollback if needed ?
One point is very important, once a server is deploy, we can't have any access to it. That's why it's better to have it running in an older version than to have it not running.
I hope that you'll understand my issue, sorry for my english
Julian
Related
I create a new package in SSIS and when I try to run the package, SSIS returns the following error (displayed in a Visual Studio Error Dialog):
"Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration"
Environment: VS 2019 with newest SSIS Extension Installed. The package appears to be created correctly and the build succeeds.
The error happens even if the package is trivial "hello world" type of package.
I found no solution to this after a fairly extensive search.
Thanks to EmersioN (https://stackoverflow.com/users/707267/emersion) for the solution. The problem in this case was the selected targeted version of SQL Server. My project was configured to target "SQL Server 2017", but was connected to a server running SQL Server 2012.
If you're seeing this error, this may be the reason.
Go to the properties page of the Integration Services project that contains the affected package. In the Property Pages dialog, navigate to Configuration Properties > General. Under the property group, Deployment Target Version, in the TargetServerVersion property drop-down, select the SQL Server version that matches the one you're connected to.
I just came across this as well in VS2019 SSDT. In my case it was a working SSIS package that after going to sleep for the night, the machine woke up and wouldn't execute the same scripts. These were my steps. Hope they help you or someone else who stumbles across this.
Open each connection within the script, Test Connection and Save
Clean the solution
Rebuild the solution
My context
Working through an SSIS tutorial using SQL Server 2019 Developer (v15.0.2080.9) and VS2019 Community (v16.11.9) to create packages using SSDT (SSIS Projects v3.15).
Packages in VS have executed without issue in the past. I then upgraded my machine from Windows 10 Pro to 11. Now, when running the same - possibly any - package I get the following error:
===================================
Failed to start project (Microsoft Visual Studio)
===================================
Cannot create a debug host for the package. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.LaunchVsDebugger(Boolean isRemoteTest, IVsDebugger iVsDebugger, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.ValidateAndRunDebugger(Int32 flags, IOutputWindow outputWindow, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, ProjectItem startupProjItem, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchActivePackage(Int32 launchOptions)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.Launch(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
===================================
Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DebugEngine.DebugEngine.LaunchDtsDebugHost(Process& process, Boolean run64bit)
at Microsoft.DataTransformationServices.Project.DebugEngine.DtsProgramNode.CreateRuntimePackageInternal(IDtsHost& host, Process& process, Package& dtsPackage)
...and the package does not execute.
What was tried
I tried/checked all 3 answers posted here.
Error persists.
This VS Dev Community's post recommended upgrading the VS extension, SSIS Projects. Since I had the most recent version installed an upgrade was not applicable, so I chose the repair option from the installer.
Error persists.
I then ran a repair on the VS2019 install. This, in turn, required another repair on SSIS Projects. (I still had both installers on my machine which made this easy.)
Error persists.
This MSDN post recommended re-registering DtsDebugHost.exe, failing that, re-installing SQL Server.
I ran the DtsDebugHost.exe /regserver command.
Error persists.
My Solution
I then chose to repair my SQL Server installation instead of re-installing. This was accomplished via the SQL Server Installation Center > Maintenance > Repair option. In my case, I chose the default instance, MSSQLSERVER.
VS now runs without the error and successfully executes the package.
I couldn't say whether my solution was solely based on the repaired SQL Server instance or a combination of other things tried and my last action. So I offer the path I took in the case of the latter.
Aside: The other choices during the SQL Server repair on my system were (1) another server instance, SQLSERVER2019, and (2) "shared components". Selecting either of those may have resolved the issue as well, but I couldn't confirm that.
In Project Property, turn off Azure-Enabled as seen in the image below. Your package will execute afterwards.
I encountered this error after upgrading to Windows 11.
I referred to the post by #steveb and went straight to his solution of repairing SQL Server (SQL Server Installation Center > Maintenance > Repair), without doing any of the other steps he tried.
And that solution worked.
I'm posting this because #steveb said he was unsure if any of his previous steps had affected the ultimate solution, and in my experience they were not necessarily needed.
I have a Mercurial server on a simple server (Virtual Machine (VM)), and about 100 users with access. And from time to time, requests have been slow.
And since I can not change the hardware of this server, because the VM server no longer has available resources, and migrating it would do a great job.
I would like to know it is possible to have 2 mercurial servers, using the same database, because this would balance the load, and in one server would put a large team, and in the other the other teams. In short, I can not mess with the server you're on today.
VM:
Windows Server 2003 SP2
1.5GB Memory
60GB HD
Settings:
Python 2.7.2
Mercurial 2.5.4
RhodeCode 1.6.0rc1
Note:
Sorry if you're confused, this question was translated via google. If you can edit and rearrange it, I'll be very grateful.
This is certainly possible. If you have shares storage RhodeCode can use the same DB and load-balance load between machines.
Btw, 1.6.0 is very old I'd take a chance at upgrading this.
A project with the following technologies and components has surfaced: to up a Web stack solution initially composed with Ubuntu, JDK, JBoss, Spring MVC 3.0+, and MySQL.
In planning this project, I have been struggling to find answers to the following questions for first steps, best practices, and sequence:
1) Does the JDK (and JBoss) need to be installed as ‘root’? (I have seen articles that mention it is not a good idea to operate in root unless absolutely necessary due to the fatal consequences.)
2) Does Ubuntu need to be installed as a Server in order to accomplish all this, or can it also be installed as a Desktop? I have not been able to determine if having a JBoss and MySQL need to be installed on top of Linux as a server.
3) Does Maven need to be used within Spring STS in order to get JBoss, and MySQL (and in the future Hibernate) to work successfully together?
4) My intent is to install in this order: a) Ubuntu -> b) Java -> c) JBoss -> d) Spring STS -> and e) MySQL. Are there any blatant conflicts in this sequence?
JBoss will require Java (recommend Java 7) before it will do anything. I don't think it really "installs" per-say, but rather just unpacks to some directory (even if you install from the package manager, it just really extracts itself). I question your need for Spring since JBoss and Java EE in general really does everything Spring does, and better now-a-days. Unless you have a specific requirement for Spring, I'd question this extra dependency.
For linux - in a high level, any OS can be a "server", all it needs is to be capable of serving things (web pages, ssh connections, etc). In M$ world, different "levels" of the OS have been specially designed based on anticipated task/workload. So for example, while Windows 7 can indeed run as a server, it was not designed for it and therefore may not be optimized or include helper utilities and tools to make life easier as a sys admin of the system. Windows Server on the other hand does include all the "normal" server tools and lots of goodies to make maintaining and setting the server up easier.
In linux land, this is no such thing. Linux is the kernel that talks back and forth with the bare metal, etc... and Distro makers will take that and build an OS around the kernel, basically just attaching any packages they feel their distro needs... such as wget, or cat, or any other standard userland apps, plus some non-standard such as mysql or java or whatever they want.
Now, some distributions of linux will tailor themselves at being "server" ready, while others will tailor themselves at being a desktop OS. The difference? It's really just whatever default packages the distribution maker decides to include or not. For example, the overwhelming majority of linux servers are run completely headless, and therefore there is absolutely no reason to have X11 and a huge bloated GUI environment installed and/or running on that system... it's pointless. Also, an "average joe" user does not need MySQL installed by default on his desktop system since it would only bloat his system and he likely won't ever use it.
So basically it comes down to default installed packages.
Some linux server distros take this further and exercise extreme caution when making updates, patches, or new releases in the name of stability and security, while on the other hand most desktop distros are more haphazard with their updates since if it breaks a home users web browser, it's probably not a huge deal... but if a server update breaks the webserver application stack, now that's a serious problem.
So you'll find server OS's like CentOS (based on upstream RHEL) are extremely slow to bring in the "latest and greatest" features that desktop OS's get early on. Their goal is high security and long term stability.
Now, for Ubuntu. While I certainty know a lot of folks run Ubuntu as their server OS choice (partly due to Amazon choosing Ubuntu as the default linux VM for their ECS cloud), but I'd really question this. Ubuntu is not focused on being a server. It's focused on being a great all-around desktop oriented OS. Yes the LTS version is meant for long term stability, but it's based out of a desktop OS, so it's still not the focus.
IMHO, I'd go with CentOS because it's free and completely binary compatible version of RHEL - and RHEL is the de-facto standard for enterprise-grade linux servers. Be aware though, the RHEL way of doing things is a bit different than the debian way -- so there is no apt-get, you must use yum install instead. Startup scripts are different and some ways of doing things are different, but really, once you know linux, you know linux.
EDIT: Also check into Jenkins - its a free opensource continuous integration system that runs on JBoss or Tomcat or any other container, and can automagically pull your code from a repo (github, git, svn, etc) and compile/package it then push it to live deployment. You setup your ANT or Maven build scripts, and it can kick off on a schedule or however you configure it.
EDIT EDIT: I'd also recommend using OpenJDK -- as it's likely included in your package manager (for just about every disto) and will be more updated than the oracle version if it's in your package manager too. I've found most "server" distros will have OpenJDK 7 while only having Oracle java 6 in their package managers. Also, installing it via the package manager will enable you to keep it updated a ton easier.
Installed as root, why not? Run as root, probably not a good idea.
If you want a desktop, install a desktop distrib. If you want a server, install a server distrib. This doesn't change what can and can't be run in the OS. It only changes what is installed by default.
Maven is a build tool. JBoss doesn't care how you build your app. All it cares about is if the application you deploy is a valid Java EE application.
No. You need an OS, so Ubuntu must come first. JBoss and (AFAIK) Spring STS need a JRE to run, as they're Java applications, so Java should be installed before them. MySQL is independent of JBoss, STS and Java, so you can install it whenever you want.
Note that if you're struggling just with this installation part, be prepared to suffer with the rest. Building a Java EE webapp is not a piece of cake, and you should probably find some experienced developer to help you, as it seems you're only beginning with Java.
I have a client, that uses SQLDMO for a portion of a custom application that was written against SQL Server 2000, and they recently upgraded to SQL Server 2008.
The majority of the app still runs fine (doesn't use SQLDMO), but the admin functions which rely on SQLDMO stopped working.
I installed the SQL2005 backward compatibility pack, and now SQLDMO partially works, i.e. I can run "select" type queries, but any "Update" queries fail with the error message:
to connect to the server you must use SQL Server management studio or sql server management objects (SMO)
Any thoughts? Should the backward compatibility pack give me ALL the functionality back, or is this a known issue?
BTW: I realize SQLDMO has been deprecated and will go away next release, none-the-less I need to do what I can to solve the problem at hand.
OK, I figured it out. Not only do you need to apply the "Backward compatibility pack" to the server, you also need to install (and register), the newest SQLDMO.DLL file on each of the client workstations.
Hopefully this save someone else a bit of time someday.
I'm just setting up the live environment for my new project. Unlike my dev and testing systems, the live environment consists of a web server (Win 2003) and a separate DB server (MYSQL).
My installation process for each release of the software is nicely scripted, giving me full rollback options etc.
However, I can't work out how to install my stored procedures within that process. I can't run a MYSQL command line because MYSQL isn't installed on the web server, it only accesses the DB via ODBC.
Is there a means by which I can run MYSQL commands on the web server, via ODBC from a command line? I really want to keep it all together so I can run "Install v123" and everything whizzes off and gets installed in one go.
There may be a more elegant solution but: I had a very similar problem a number of years ago, and I eventually just wrote a little stand alone program to run my scripts at the end of the install.
Another common option is to have them run as part of a configuration utility/page the user goes to after setup, but I'm assuming you want to keep this as a 1 step installation.