Powershell:
Get-AppxPackage -allusers | foreach {Add-AppxPackage -register "$($_.InstallLocation)\appxmanifest.xml" -DisableDevelopmentMode}app.set('port', (process.env.PORT || 5000));
//For avoidong Heroku $PORT error
app.get('/', function(request, response) {
var result = 'App is running'
response.send(result);
}).listen(app.get('port'), function() {
console.log('App is running, server is listening on port ', app.get('port'));
});
if(process.env.url){
http.get(process.env.url);
}
setInterval(function(){
http.get(process.env.url);
}, 300000)Error details: Instance does not have a volume attached at root (/dev/sda1)
This error comes when Device name given while attaching the root volume differs from Root device attached to EC2 instance during launch.
How to Resolve This Error
In order to resolve this error follow below steps:
Step1: Note down the device name in error while starting the EC2 instance.
In the above screen shot error is related to device name /dev/sda1. We need to use same device name while attaching the volume to EC2 instance.
Step2:Detach the currently connected Volume with EC2
- Go to ELASTIC BLOCK STORE –> Volumes and select respective attached volume . This volume will be having status as “in-use”.
- Then click on Detach volume option from Action drop down menu.
Step3:Attach volume to EC2
Try to attached same volume to EC2 instance. However make sure that you are not using default “Device” such as “/dev/sdf” as below while attaching volume to EC2 instance.
Do not Use below by-default Device name.
Instead Use Device name as /dev/sda1 which we have noted down in the step1 as below and click AttachButton:
Step4:Start EC2 instance
This time when you try to start the instance, the error “Instance does not have a volume attached at root (/dev/sda1)” will not occur and your EC2 instance will be start successfully.
Original article sourced from:
https://linuxroutes.com/how-to-resolve-instance-does-not-have-a-volume-attached-at-root-dev-sda1-error/
Now personally, I’m not exactly a big Apple fan, especially since some of their hardware tends to be a little overpriced. But when I started looking for a nice keyboard to go with my new desktop build, I quickly realized that my desires aligned quite nicely with those of our late pomaceous demigod, The Almighty Steve.
The Illusion of Choice
My requirements in a keyboard are simple enough, really. Sorted by importance, they go a little like this:
- Low-profile chiclet keys
- Wired
- Comfortable to type on
- Good build quality
- Not horribly ugly to look at
… and that’s about it. No crazy rainbow LED backlighting, no built-in LCD that tells you the weather and suggests going outside for some exercise, no customizable command macros, just a simple keyboard I can write code and game with.
I’m all about efficiency, so I’ve come to love laptop-style chiclet keys than only need to be depressed a few millimeters. I feel like I’m wasting so much energy when I’m pushing an old clunky mechanical key down into the Earth’s mantle just to get one lousy letter out of it. And forget this wireless nonsense of pairing devices and changing batteries all the time. Wireless tech is cool and all, but until it’s been better refined I’ll stick to untangling my rat’s nest of cables once a year, thanks.
So wasn’t I pleasantly surprised to learn that Apple’s standard wired keyboard is only $50, when anything comparable from Logitech, Microsoft or SteelSeries was double the price and double the ugly. I’ve been using it for over a week now, and I’m happy to report that it’s the best feeling keyboard I’ve ever used, so I highly recommend it.
There are a few quirks to using an Apple keyboard on a Windows machine, of course, but nothing we can’t fix with some program downloaded off the internet. Your two choices here are AutoHotkey and SharpKeys. The former runs as a script in the background that intercepts key presses and can make them do something else entirely, like a multi-key press macro, which makes it far more powerful. But again, since I’m a little obsessed with efficiency, it just wouldn’t do for me to have a script that starts up with Windows on every boot, eating precious CPU cycles while I wait for code to compile. So, I went with SharpKeys, which has the added bonus of being much easier to use than AutoHotkey. You don’t have to write any scripts, just a few clicks is all you need to set yourself up permanently.
Setting Up SharpKeys For The Apple Keyboard
The good news is that the keyboard itself is plug-and-play with a Windows machine, with almost everything working as expected. But if you’re anything like me, you probably want your shiny new device to match the functionality of a standard keyboard layout as closely as possible. The first step here is to identify the problem children when using the keyboard with stock settings:
- The Windows and Alt keys are swapped, on both the left and right of the spacebar
- There’s no Print Screen, Scroll Lock, Pause/Break, or Insert keys
- The Eject and Function keys don’t do anything
So, with this in mind, I suggest the following SharpKeys remapping:
We’ve now fixed almost everything: the Windows and Alt keys are swapped back to the way they should be, and we get our handy Print Screen, Scroll Lock, and Insert keys back. The only problem is that Function and Eject are not recognized by SharpKeys, and hence we can’t do anything with them. You could probably overcome this using AutoHotkey, but I didn’t bother trying. The good news, however, is that you have four extra function keys you can use for whatever you want (I went with music controls), which gives us the following effective keyboard:
Now, I’m sure there’s a purist out there somewhere, screaming at his monitor that this doesn’t match the One True Keyboard Layout. Well, unfortunately, Pause/Break give SharpKeys some trouble by having a non-standard keycode, so I just didn’t bother with it. And let’s be honest, when’s the last time you pressed it? (If you answered “changing my environment variables, duh!” then you’ve earned yourself a cookie! But it’s still incredibly rarely, c’mon…) So, I plugged Insert there, rather than on the non-functional Function key (oh the irony). Finally, since Clear already behaves as Num Lock out of the box, we’ve got ourselves keyboard we can work with. Enjoy the shinies!
Original article taken from:
http://nullcandy.com/using-an-apple-keyboard-with-windows-7/
This Post will show you how to deploy a Remote desktop session server (RDSH) in a workgroup (non Domain).
This deployment is Session based and will allow the use of desktop sessions. The down side to having a none domain joined Session host is that you will need to create users on the host and configure local Group policy’s to restrict user access.
I have deployed a single server (non domain Joined) with Server 2012 R2.
Configuring the FQDN
As this is a workgroup server (non Domain) you will need to configure the Fully Qualified Domain name.
This can be done under system Properites
Deployment
We are going to deploy the RDS 2012 Session Host Role and the RDS licencing role
This image shows the roles and features that have been installed, as you can see the session host and remote desktop roles are shown as installed.
Adding the RDSH Certificate
Firstly you will need to import your certificate to the Local Computer , Personal Folder as shown in the screen shot.
Before configuring RDSH Servers you will see a warning stating that the certificate is untrusted.
This is because the configuration data for RDSH is stored in the WMI, Win32_TSGeneralSetting class in WMI in the rootcimv2TerminalServices namespace. You will need to change the certificate from default using the following commands.
Firstly, You will need to find the certificate thumbprint.
You can also use PowerShell to find the Thumbprint:
Get-Childitem Cert:\LocalMachine\My
Run one of the following cmds to apply the new certificate to the Win32_TSGeneralSetting:
Command Prompt:
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="Thumbprint"
PowerShell Cmd:
$path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="THUMBPRINT"}Licencing
You will need to configure the licencing to allow multiple users to connect via sessions.
Adding Users
Add the users under Computer Management, Local Users and groups
Add the users to the remote desktop group.
you can also do this in the server manager under local Computer
As you are connecting to the RDSH host locally, use local\username
Applying Security
As you can see from the screen shots, users cannot install roles and features or modify Group Policy’s with out Administrator permissions, I would recommend configuring local group policy’s to lock down remote users, as you would in a Domain. You can access the local group policy editor via MMC and add the snapin for the Group policy editor.
Administering sessions
In the Group Policy editor, I have set the idle limit on the sessions so that if users are inactive for over a hour their session will be terminated.
.
You can also manage your users from the task menu
by right clicking on the user, you get a number of options including disconnecting the user, Sign them off, sending messages, and Connect which allows you to connect to a user session. You will need to be the user in question to do this.
When users are finished with their sessions they simply sign out, or they can disconnect. There is no option to shut down the server for remote session users.
If you are receiving one of the below error messages, follow the configuration steps listed to resolve your issue.
“Remote Desktop licensing Mode is not configured”
“The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license”
1) Open Command Prompt (as admin).
2) Type in the following command:
a. gpedit.msc
Navigate to:
a. Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing
4) Select the policy: “Set the Remote Desktop licensing mode”. Click Edit.
a.
5) Select “Enabled”, and change the dropdown to “Per User” (or device if you purchased device CALs). Click Apply.
a.
6) Select the policy “Use the specified Remote Desktop license servers”
7) Select “Enabled”, then input the name or IP of the server you installed the licenses on (it could be the current server, or another server; in most cases you can just enter the name of the server you are on). Click Apply.
Note: When in doubt, use the local server IP. This can be found in Server Manager.
a.
8) Navigate to:
a. Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections
9) Edit the policy “Limit number of connections”.
10) Select “Enabled” and change the number to “999999”. This will allow unlimited remote connections. Click Apply.
a.
11) In order to apply changes, the group policy must be updated. To initiate this, open Command Prompt (as admin) and enter the following command:
gpupdate.exe /force
Note: This step is required for any changes to take effect.
After following the above steps, users will be able to remote into the specified server.
Still having issues?
In some cases a trial of Remote Desktop Services will leave a registry key that requires removal. See the steps below to check if this key is set, and how to remove it.
1) Open “regedit”:
a.
2) Navigate to the following folder:
a. HKEY_LOCAL_SYSTEM \SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
3) Inside of the RCM folder you may see a folder titled GracePeriod with a REG_BINARY key. If the GracePeriod folder exists, the REG_BINARY key must be removed.
a.
Note: Moving forward ensure that you are signed in as an administrator. The following steps will not work unless your current account has admin privilages
4) Right-click the GracePeriod folder and select “Permissions”.
5) Select the “Security” tab and click “Advanced”.
a.
6) Change the owner to “Administrator”
a. Click “Change”.
b. Type “Administrator” in the large box and click Check names.
c. Click “Ok”
7) Apply Settings.
8) In the “Security” tab, select Administrator(s) and ensure “Full Control” is selected. Then click “Apply”.
a.
9) Now that we have ownership of the folder, we can delete the REG_BINARY key. Right-click the “L$RTMTIMEBOMB_…” key and select “Delete”. If the permissions were set correctly the key will delete. If you see anotice regarding permissions, please check steps 4-8 again.
10) After the key is removed we can reboot the server and resume normal function. Complete a server reboot at your convenience to finalize the registry key removal.
- Run Drive File Stream install on the Win10 x64
- Copy files from C:\Program Files\Google\ to the new WinServer system
- Copy registry entries HKLM\SOFTWARE\Google\DriveFS to the new system
- Install driver by clicking Install on C:\Program Files\Google\Drive File Stream\Drivers\[version]\googledrivefs[version].inf
- Register DLL in cmd: regsvr32 “C:\Program Files\Google\Drive File Stream\[version]\drivefsext.dll”
- Reboot
- Run C:\Program Files\Google\Drive File Stream\[version]\GoogleDriveFS.exe and sign-in
Setting up VS Code To Debug in Node.js
Sorry, I couldn’t resist this meme — it’s just so appropriate. Ok, so let’s walk through setting up VS Code to debug Node. I’ll assume you’ve already downloaded VS Code from the link I posted above, so we’re ready to start setting it up.
Open up Preferences > Settings and in the search box type in “node debug”. Under the Extensions tab there should be one extension titled “Node debug”. From here, click the first box: Debug > Node: Auto Attach and set the drop down to “on”. You’re almost ready to go now. Yes, it really is that easy.
Now, go to your Node.js project file, and set some breakpoints by clicking on the left hand side of the file wherever you’d like to see your code stop, and in the terminal type node --inspect <FILE NAME>. Now watch the magic happen…
VS Code Debugging in Action
If you need a Node.js project to test this out with, you can download my repo here. It was made to test different forms of streaming large amounts of data with Node, but it works really well for this demo. If you’d like to see more about streaming data with Node and performance optimization, you can see my posts here and here.
Once you hit Enter, your VS Code terminal should turn orange at the bottom to indicate you’re in debug mode and your console will print some message along the lines of ‘Debugger Attached’.
Once you see this happening, congrats, you’re running in debug mode in Node.js!
Now, you can see your breakpoints in the bottom left corner of the screen (and can toggle them on and off with the checkboxes), and you can step through the code just like you would in a browser with the little play, step over, step in, restart, etc. buttons at the top center of the IDE. VS Code even highlights the breakpoint and line you’ve stopped on with yellow, making it easier to follow along.
As you step from breakpoint to breakpoint, you can see the program printing out the console.logs in the debug console at the bottom of the VS Code IDE and the yellow highlighting will travel with you, as well.
As you can see, as I progress through the program, more prints out to the debug console the further through the breakpoints I go, and along the way, I can explore the objects and functions in the local scope using the tools in the upper left hand corner of VS Code, just like I can explore scope and objects in the browser. Nice!
That was pretty easy, huh?
Conclusion
Node.js debugging doesn’t have to be the headache it was in the past, and it doesn’t need to involve 500 console.log()s in the codebase to figure out where the bug is.
Visual Studio Code’s Debug > Node: Auto Attach setting makes that a thing of the past, and I, for one, am so thankful.
Check back in a few weeks, I’ll be writing about end-to-end testing with Puppeteer and headless Chrome or using Nodemailer to reset passwords in a MERN application, so please follow me so you don’t miss out.
Thanks for reading, I hope this gives you an idea of how to more easily and effectively debug your Node.js programs with a little assistance from VS Code. Claps and shares are very much appreciated!
DECLARE @name VARCHAR(50) -- database name
DECLARE @path VARCHAR(256) -- path for backup files
DECLARE @fileName VARCHAR(256) -- filename for backup
DECLARE @fileDate VARCHAR(20) -- used for file name
-- specify database backup directory
SET @path = 'C:\Backup\'
-- specify filename format
SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112)
DECLARE db_cursor CURSOR READ_ONLY FOR
SELECT name
FROM master.dbo.sysdatabases
WHERE name NOT IN ('master','model','msdb','tempdb') -- exclude these databases
OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
SET @fileName = @path + @name + '_' + @fileDate + '.BAK'
BACKUP DATABASE @name TO DISK = @fileName
FETCH NEXT FROM db_cursor INTO @name
END
CLOSE db_cursor
DEALLOCATE db_cursor