One place for hosting & domains

      Survey: Monitoring and OS Maintenance are IT Pros Biggest Infrastructure Time Wasters

      If time is considered a finite resource, IT pros are feeling a shortage.

      For INAP’s second annual State of IT Infrastructure Management report, we asked IT professionals to list the routine infrastructure activities taking too much and too little of their time. Once again, monitoring topped the “too much time” list, while designing and implementing new solutions ranked No. 1 in the “not enough time” category.

      Overall, 59 percent of IT pros are frustrated by the time spent on routine infrastructure activities and 84 percent agreed that they “could bring more value to their organization if they spent less time on routine tasks”—up 7 points from 2018.

      The survey was conducted late last year among 500 IT senior leaders and infrastructure managers in the United States and Canada. The margin of error was +/- 5 percent.

      Participants also shared how often their personal time is interrupted and how they would spend their time if they were given 16 hours back to use as they please.

      Check out the results below and download a copy of the full report here.

      How IT Pros Spend (And Don’t Spend) Their Time

      Here’s the full list of routine infrastructure activities alongside IT’s assessment of whether each is getting the attention it deserves.

      IT's Time

      Only 23 percent of participants said they don’t spend enough time monitoring infrastructure, which is less than half the rate of those who consider this routine activity to be something that is eating into time that could be spent elsewhere (48 percent).

      Operating system and hardware maintenance came in second and third, at 42 percent and 40 percent, respectively.

      Nearly half (47 percent) of IT pros want to spend more time on designing and implementing new solutions, compared to 28 percent who already spend too much time.

      IT pros remain polarized, as they were in the 2018 report, as to whether the amount of time spent securing their infrastructure is hitting the mark, with 39 percent saying it’s too much and 42 percent saying it’s not enough. Information security management/vulnerability migration is also the activity where the highest percentage of IT pros went one way or another on the issue, as only 19 percent fell into the “neither” category.

      Senior leaders were far more likely to say they spend too much time on security compared to non-senior infrastructure managers—30 percent vs. 13 percent. They were also more likely to say they don’t focus enough on OS maintenance—20 percent vs 6 percent of non-leaders.

      How IT Pros Would Like to Spend Their Time

      Survey respondents say their personal time is disrupted by work responsibilities related to server and/or cloud infrastructure an average of 6.24 times per month—up slightly from 5.9 times in 2018’s report.

      With so much time—on and off the clock—being dedicated to upkeep and maintenance, we once again asked, “What would you do if we gave you 16 hours back in your week?”

      16 hours

      Application related answers make up three of the top four activities this year, with “enhancing existing applications” and “optimizing existing environments for application performance” coming in third and fourth, respectively. Reclaiming work-life balance fell to second, after claiming the top spot in 2018.

      In the first annual State of IT Infrastructure Management report, IT pros noted that their departments are the key driver of their organization’s digital transformation initiatives, but they are spending too much time on routine tasks, focusing on functions that are “just keeping the lights on.” This sentiment continued in 2019. The list of activities noted in the chart above can be considered the opportunity costs of these routine tasks.

      Have you read checked out our second annual State of IT Infrastructure Management report yet? If not, download a free copy and get your report card for the hybrid IT and multicloud era:

      Laura Vietmeyer


      Source link

      IT Horror Stories, Just in Time for Halloween

      From out of control on-premise fires to misplaced tequila bottles that delete customer data [NSFW—language!], there’s a lot that can go nightmarishly wrong in the tech world. While we don’t often want to ruminate on what’s beyond our control, Halloween is the perfect time to face our fears, and entertain ourselves in the process.

      In celebration of the spooky season, below are IT horror stories to give you the chills, or maybe just a laugh.

      Dropped Database

      Our first story comes from Paweł Kmieć, a senior managing developer, who shared with ThinkIT an all-important lesson about knowing your environment. Kmieć was developing a reporting application. The deadline was drawing near and everything was going well. It was time to move the application from the development environment into production.

      As Kmieć tells it, “I happily launched all necessary data imports and spent quite a lot of time manually verifying and cleaning data afterwards. The day before [the] demo to our CFO, I mistook the dev database with the newly created production database and issued a statement which still haunts me ten years later: DROP DATABASE.”

      Kmieć reports that he hasn’t developed in production since this incident.

      Beer Goggles

      Easy jobs can sometimes end up being harder than expected. Egor Shamin, a system administrator, shared with us a story from 2012 at a previous job. He and a coworker traveled to do what he describes as a “cushy job”—building a network for 30 PCs.

      The first day of work went smoothly, and they only had to pin out network sockets and install patch panels, so they chose to spend the rest of the night relaxing. After sharing a few drinks together, Shamin turned in for the night, but his coworker kept on drinking.

      “We were both late to work the next day, which was already a bad start,” Shamin recounts. “But what made it worse was that we needed to run one more wire, and the line we had physically didn’t allow it. My partner decided that he’d be able to neatly widen the line with the drill. Thanks to the nine beers he’d had the previous evening, all the guy managed to do using the drill was cut down all of the wires.”

      The pair ended up working late into the night making wire twists since they didn’t have any other cable. Shamin says that, to his credit, his coworker did most of the job himself. And in the end, the network worked perfectly fine.

      Getting Squirrely


      For all of our efforts to control our environment, nature often has other plans. Did you know that squirrels are among the reasons that data centers sometimes go down? Reddit user JRHelgeson had a brush with a squirrel squatter himself while moving customer equipment into a new facility.

      There were a number of things he saw that could go wrong. The furry creature might burrow under the raised flooring and build a nest in the fiber bundle. Or he might have the run of the data canter by getting up on an overhead ladder. JRHelgeson knew his team had to act fast to evict the gate crasher.

      “We had guys with packing blankets moving in from three sides to get him cornered and he scurries up to the top of a rack filled with customer equipment. As they are closing in, the squirrel starts growling and—preparing for a fight—empties his bladder, raining down on the servers in the rack.”

      The team finally caught the squirrel and got him out. Fortunately, no real damage was done since the top of the servers were sealed. From that day forward, if the outside door is open, the interior door is closed, or an alarm will go off.

      The Little Patching Server That Could

      The web has a treasure trove of nightmare stories if you know where to look. The next story, featured on Global Knowledge, was shared by Derrick B., and serves as a reminder to never do patching work in the middle of the business day, even if the patching isn’t expected to have a major impact.

      Derrick’s team was all set to patch Windows servers. Change Management approved their patching and timing, which was intended to occur after hours to minimize impact. Everything started off well, until the patch management server crashed and wouldn’t reboot. Calls were put out to hardware support for troubleshooting, but the field tech didn’t arrive until the next day. The tech ran diagnostics and solved the problem, which only led to bigger issues.

      “The monitoring console lit up like a Christmas tree and pagers started going off all around the server and application admins’ aisles,” Derrick says. “Servers were going down all across the enterprise. Senior managers started calling to find out what the heck was going on. Customers were being impacted as applications became unavailable.”

      It turns out the patching server just wanted to do its job. It has set a flag to run the patching jobs before crashing and picked right up where it had left off as soon as it was repaired.


      Cleaning up databases should always be done with great care. GlowingStart founder Alex Genadinik shared his horror story with Business News Daily, recounting a time when he accidentally deleted around 26,000 business plans on his apps.

      “I was cleaning up some old tables in a database and noticed a table with a weird table name. I thought that it was something experimental from a long time ago and deleted it,” Genadinik says. “Then, literally five minutes later, I started getting emails from my app users that their business plans were deleted.”

      With the number one function of his apps wiped out, Genadinik had a big problem on his hands. He went to work with his hosing provider and was able to have the database restored within a day after paying a fee. Talk about a scare!

      Gone Phishing

      PhishingUnfortunately, the next story is becoming an all too common occurrence for IT professionals. Our own Victor Frausto, security engineer, shared a past incident with a phishing email that was spammed to employees from one user’s account. Even though the attempt was caught early and minimized, the resulting work to reset the account and ensure the malicious email didn’t spread made for an eventful day at work.

      “We had to disable the compromised account, scan the laptop, re-enable the account and change the password,” Frausto said. “And then we had to that for anybody who opened the spam email and clicked on the malicious link. Scary!”

      Sometimes, the scariest thing in tech can be the feeling that you have to go it alone. Check out INAP’s managed services and disaster recovery options to get a handle on your IT nightmares!

      Happy Halloween!


      Laura Vietmeyer


      Source link

      How To Set Up Time Synchronization on Debian 10


      Accurate timekeeping has become a critical component of modern software deployments. Whether it’s making sure logs are recorded in the right order or database updates are applied correctly, out-of-sync time can cause errors, data corruption, and other difficult issues to debug.

      Debian 10 has time synchronization built in and activated by default using the standard ntpd time server, provided by the ntp package. In this article we will look at some basic time-related commands, verify that ntpd is active and connected to peers, and learn how to activate the alternate systemd-timesyncd network time service.


      Before starting this tutorial, you will need a Debian 10 server with a non-root, sudo-enabled user, as described in this Debian 10 server setup tutorial.

      Step 1 — Navigating Basic Time Commands

      The most basic command for finding out the time on your server is date. Any user can type this command to print out the date and time:


      Wed 31 Jul 2019 06:03:19 PM UTC

      Most often your server will default to the UTC time zone, as highlighted in the above output. UTC is Coordinated Universal Time, the time at zero degrees longitude. Consistently using Universal Time reduces confusion when your infrastructure spans multiple time zones.

      If you have different requirements and need to change the time zone, you can use the timedatectl command to do so.

      First, list the available time zones:

      • timedatectl list-timezones

      A list of time zones will print to your screen. You can press SPACE to page down, and b to page up. Once you find the correct time zone, make note of it then type q to exit the list.

      Now set the time zone with timedatectl set-timezone, making sure to replace the highlighted portion below with the time zone you found in the list. You'll need to use sudo with timedatectl to make this change:

      • sudo timedatectl set-timezone America/New_York

      You can verify your changes by running date again:


      Wed 31 Jul 2019 02:08:43 PM EDT

      The time zone abbreviation should reflect the newly chosen value.

      Now that we know how to check the clock and set time zones, let’s make sure our time is being synchronized properly.

      Step 2 — Checking the Status of ntpd

      By default, Debian 10 runs the standard ntpd server to keep your system time synchronized with a pool of external time servers. We can check that it's running with the systemctl command:

      • sudo systemctl status ntp


      ● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-07-31 13:57:08 EDT; 17min ago Docs: man:ntpd(8) Main PID: 429 (ntpd) Tasks: 2 (limit: 1168) Memory: 2.1M CGroup: /system.slice/ntp.service └─429 /usr/sbin/ntpd -p /var/run/ -g -u 106:112 . . .

      The active (running) status indicates that ntpd started up properly. To get more information about the status of ntpd we can use the ntpq command:


      remote refid st t when poll reach delay offset jitter ============================================================================== 0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 + 2 u 12 64 377 39.381 1.696 0.674 + 2 u 6 64 377 22.671 3.536 1.818 3 u 43 64 377 12.012 1.268 2.553 2 u 11 64 377 69.922 2.858 0.604 2 u 10 64 377 35.362 3.148 0.587 # 2 u 65 64 377 42.380 1.638 1.014 +t1.time.bf1.yah 2 u 6 64 377 11.233 3.305 1.118 *sombrero.spider 2 u 47 64 377 1.304 2.941 0.889 +hydrogen.consta 2 u 45 64 377 1.830 2.280 1.026 - 2 u 42 64 377 29.077 2.997 0.789 #horp-bsd01.horp 2 u 39 64 377 16.165 4.189 0.717 2 u 46 64 377 27.914 3.717 0.939

      ntpq is a query tool for ntpd. The -p flag asks for information about the NTP servers (or peers) ntpd is connected to. Your output will be slightly different, but should list the default Debian pool servers plus a few others. Bear in mind that it can take a few minutes for ntpd to establish connections.

      Step 3 — Switching to systemd-timesyncd

      It is possible to use systemd's built-in timesyncd component to replace ntpd. timesyncd is a lighter-weight alternative to ntpd that is more integrated with systemd. Note, however, that it doesn't support running as a time server, and it is slightly less sophisticated in the techniques it uses to keep your system time in sync. If you are running complex real-time distributed systems, you may want to stick with ntpd.

      To use timesyncd, we must first uninstall ntpd:

      Then, start up the timesyncd service:

      • sudo systemctl start systemd-timesyncd

      Finally, check the status of the service to make sure it's running:

      • sudo systemctl status systemd-timesyncd


      ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: active (running) since Wed 2019-07-31 14:21:37 EDT; 6s ago Docs: man:systemd-timesyncd.service(8) Main PID: 1681 (systemd-timesyn) Status: "Synchronized to time server for the first time (" Tasks: 2 (limit: 1168) Memory: 1.3M CGroup: /system.slice/systemd-timesyncd.service └─1681 /lib/systemd/systemd-timesyncd

      We can use timedatectl to print out systemd's current understanding of the time:


      Local time: Wed 2019-07-31 14:22:15 EDT Universal time: Wed 2019-07-31 18:22:15 UTC RTC time: n/a Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no

      This prints out the local time, universal time (which may be the same as local time, if you didn't switch from the UTC time zone), and some network time status information. System clock synchronized: yes means that the time has been successfully synced, and NTP service: active means that timesyncd is enabled and running.


      In this article we’ve shown how to view the system time, change time zones, work with ntpd, and switch to systemd's timesyncd service. If you have more sophisticated timekeeping needs than what we’ve covered here, you might refer to the offical NTP documentation, and also take a look at the NTP Pool Project, a global group of volunteers providing much of the world's NTP infrastructure.

      Source link