Posts made by matteo nunziati

@JaredBusch well never considered the workload on servers. I don't know how they manage it! maybe not so many use unattended upgraqdes in debian.

I've reversed the IP: yukinko.canonical.com.
I've accessed it via ftp on google chrome and everything seems in place. via ftp I'm also able to download the tar, here.
maybe they have fixed something in the while?

sorry I've badly worded it.
In ubuntu/debian they per default schedule cron.{daily,weekly,monthly} in crontab and they run at specific days/weeks.
anacron is not there. you have to install it. it is not the default, and jumps in only if you install it!

utente@debian:/etc$ cat crontab
#/etc/crontab: system-wide crontab
#Unlike any other crontab you don't have to run the `crontab'
#command to install the new version when you edit this file
#and files in /etc/cron.d. These files also have username fields,
#that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

by default debian is deterministic while centos is fuzzy. while in either case the distro default makes your scripts run, their approach is different.

@scottalanmiller it is default because in the default install the crontab is empty and cron.daily, cron.weekly etc.. are all delegated to anacron. And these folders are already populated with distro "native" jobs, which run basically at random days, depending on when you have installed the machine.

It is counter intuitive to me: they can run, they are scheduled to run, but you can not control exactly in which day. weird.
In ubuntu I put scripts in daily/weekly and so and then I know when the trigger starts (ok neglect the fuzzification of delays) because anacron is declared in the crontab.

This is not the case with centos.

I find the folders really useful to collect scripts I want to run at given time deltas (e.g. backups...) I'm not used to set a crontab line for each job, as I tend to collect jobs on daily or weekly intervals.
It is a non issue but still a strange default.

well yes, simply it sounds weird to me that an enterprise distro per default uses what is basically a fuzzy job scheduler.
forcing jobs via cron is trivial, but I was courious about the default behavior and the rational behind it. this is simply not the case on debian based distros.
Next time I will check on Suse.

from the man page:
/var/spool/anacron
This directory is used by Anacron for storing timestamp files.

let's check those files

@scottalanmiller I can't imagine there is no way to force a proper restart an a given day-of-week. again: weird.

@scottalanmiller so I've built that server on a friday maybe... don't remember...

@scottalanmiller it is not it says anacron runs every 7 days. but which is the 7th day???? why friday not saturday?

the anacron man page says:

quote:
For each job, Anacron checks whether this job has been executed in the last n days, where n is the period specified for that job. If not, Anacron runs the job's shell command, after waiting for the number of minutes specified as the delay parameter.

After the command exits, Anacron records the date in a special timestamp file for that job, so it can know when to execute it again. Only the date is used for the time calculations. The hour is not used.

the cron file is empty by default.
anacron conf file to not declare when the week finish/start! even the anacron man page to not declare anything!
Again, on debian cron explicitly raises an anacron job on sunday, not here on centos. weird.

@scottalanmiller that's ok, but this doesn't answer the question: where -by jove- anacron+systemd hide the exact execution day for a weekly job?!

My centos 7 machine has a number of cron.{daily,weekly,monthly} scheduled works.
by default crontab in Centos 7 is empty and cron jobs are executed by anacron according to its conf file.
This is ok for me, but one thing I'm missing is where the anacron definition of week/month is located.

I mean, e.g., that the weekly jobs are run on friday. This is ok for me but I've searched a bit around and I've not found any setting for move the weekly execution to -say- Sunday.

On debian like distros the setup is slightly differtent and you can easily adjust the execution day in crontab. Everyone is just saying: put your cron.weekly job in crontab even on centos and avoid anacron to run the job. But this is not the solution I'm searching for.

any hints?!

tbh I think that speed really matters only after you scale a bit. having to administer a few tens of VM is not so influenced by speed. having to manage few hundreds is a different thing.

I've choosed ansible in the past because you have less stuff to learn at first and I prefer the no-agent approach (and usually I have an ssh connection open anyway). but my needs are really limited.

btw, zeromq is the fastest thing you can have in the python world, so if speed really matters, there is no other solution than salt.

It depends on what you want: virt-manager is considered the de-facto standard with few servers and VMs. Windows support is a mess in my experience. My workstation is a win10 machine with a linux VM constantly spawned, as my company uses win10 everywhere but I need a lot of linux stuff. So, when I need to go back to VM admin I simply open virt-manager in the linux VM on my workstation <- hoestly I do this rarely as my machine are created and kept running all the time.

Another tool for lightweight admin, still a bit lacking in features, is webvirt manager. It is a web app that you can even virtualize on a KVM host, then, you can connect the webvirt VM to the host (a la XOA).

I've use it for a while at the beginning but then I've gone back to virt-manager.

Moving to a more complex setup you could mind about ovirt: it is an orchestrator a la vServer and it requires a lot of stuff installed on top of libvirt-kvm. So, unless you need something like a data-center pane, avoid it. It will requires a lot of resources and setup.

On my side I've used Ansible a bit just for a small activity - more of a test- just because the learning curve is smoother: Salt has a more enterprise approach since day-0, which is not something I was in search for at the time.

@scottalanmiller have you seen this? It is not the first time I listen to people who dislikes the community support on ansible.
Complains about community/support are not to be neglectable to me, when we talk about community supported SW.

It is basically about the scale of your job: do simple/small things, even if a lot: go ansible, maybe slower but easier to start with and poke around. If performance is a major hit and/or you are going to run complex devoperated networks of servers then Salt is a better investment in the long run.

@scottalanmiller yeah, I was aware of the performance of netgear stuff. Simply I was not sure about quality. As a consultant in machine vision I always recommended netgear for small prosafe switches to put on top of machinaries. It was simply reliable "enough", cheap, and fast (which you want with say 4x5+ Mpx cameras and constrained timings)!

@scottalanmiller said in Where to buy Ubiquiti in Italy:

I have never heard of a business using them, ever

Now you know we have 2 dlinks. I've found them in place and both are bugged. One even loose config (all: ip, vlan, everything!) in case of power failure. The other isn't able to encapsulate printers packets. don't ask me why. I've had to plug a 10€ spare dlink 5port switch to encapsulate a number of printers.

btw, we also have 2 netgear and 1 used hp procurve 3400 cl. for the sake of completeness I was going to by a linksys too... just to have them all

On the opposite everyone in the supply chain who wants to talk about "reliable" stuff offers dell/hpe-aruba now in my area. Cisco is too much expensive, often. And with Cisco if you go SMB you get really bad stuff.

@ntoxicator when you grab a snapshot on libvirt/kvm is like if you grab a snapshot in LVM or ZFS: the snap is a (tempeorary) log of changes since it was taken (usually, but not necessarily a COW). it is used to allow the freeze of the data at a given time, infact the actual VM disk is not written anymore, but the snapshot is.
when you have done with the processing of the VM disk (whatever this working on is) you re-merge back the snapshot (you commit it) so that the actual VM disk gets all the write changes occurred between the snapshotting and the processing of the VM disk.
this ensures that the VM disk doesn't change while you backup it!
**note ** that this not implies that the disk is in a coherent state: it is simply frozen. the fact that the disk is correctly flushed and a proper write barrier is posed on it when snapshotted depends on other factors, which kvm honors via host/guest FS settings.
A brief about barriers is here. Here is a description of what to expect from a KVM/libvirt snapshot.

@Mike-Davis I was thinking about my company, here everyone sells aruba+hpe or dell stuff...
then you have "lower level" resellers, those who server smaller companies, and they go all dlink.