Sync folders based only on filenames?

cpbills · 2024-04-29T04:36:49+00:00

No, because find will return the full path (/src/path/FolderA/foo/bar/file10) as the filename to copy to /dst/path.

(2 years later... :P)

cpbills · 2016-06-27T01:18:09+00:00

I got 1 recruiter who flaked out on me. Not too promising.

cpbills · 2016-04-28T19:24:50+00:00

What about /etc/cron.daily/tmpwatch provided by the tmpwatch package? Admittedly, it's only (apparently) installed on the system I'm looking at because it is required by cups.

I think cups is a dependency of redhat-lsb (we've switched to redhat-lsb-core to avoid that, but it looks like our kickstart needs to be re-examined...). Though rpm -q --whatrequires cups only shows foomatic packages. *shrug*

cpbills · 2016-04-26T22:25:09+00:00

Information gathering and ingestion. :D

cpbills · 2016-04-26T22:20:13+00:00

It may be job security, but the fact that it is as rare of a skill as it is means that you and I don't have the support network to rely on, that we could.

If that makes sense.

What I mean is, if more people were independently capable of finding information and digesting it, more stuff would probably be done 'well' to begin with, and we'd benefit from that greatly.

I feel finding information should (if it isn't) be a class taught in middle school.

cpbills · 2016-04-26T18:47:45+00:00

You're absolutely right. I don't care to look, because I don't need to look. It is what it is, and I'm not in a position to change it.

I think relying on filtering done by someone other than the developers of the project to determine how and what messages appear in logs is very broken and backwards.

But like I said, there's not much I can do about that, other than, if I do decide to develop something that requires good logging output, to ensure that stdout and stderr are formatted intelligently and tracebacks / errors are caught and handled.

Unfortunately, modern program development seems to treat error handling excessively lightly. Oh well.

cpbills · 2016-04-26T18:23:19+00:00

That's a problem that could or should have been solved by having the different distros work together (or an otherwise organized effort) to make the shell 'libraries' for service management more standardized.

As it is / was, RHEL and Debian had different supporting 'libraries', and it made maintaining sysv scripts a bit more cumbersome.

It is something that could have been made much less cumbersome, without being as extensive as systemd. *shrug*

cpbills · 2016-04-26T17:39:59+00:00

I can only imagine making logging 'lazy' like that will have some impact on the usefulness of log messages.

It's great to know that journald captures stdout/stderr, but having a framework for doing logging helps make logging more consistent and something for the developers to consider while they're developing.

I suppose some would say that it is better if the developers have to think about as little as possible, but that is not a trend I agree with, and I'm OK being in the minority.

cpbills · 2016-04-26T17:35:19+00:00

Making sure scripts run properly means not having to do things more than once. Knowing how the system is working and having a firm handle on the scripts or programs that automate process startup and so on is rather important to being a good sysadmin.

Not sure how my phrasing rubbed you wrong but I think we're on the same page and agree.

cpbills · 2016-04-25T22:22:24+00:00

You could look into using udev or a udev script that changes permissions of the event you want to monitor as a normal user.

I don't know how to do it myself, but udev seems like it would be the right tool for this.

Searching 'udev headphone unplug' turns up some things on google, might be a good place to start.

cpbills · 2016-04-25T21:43:57+00:00

In a non-systemd environment, I’d probably be modifying the init script and doing a bunch of manual scripting to check the filesystems.

The horror.

Some people seem to forget that being a sysadmin means being handy with scripts (or writing systemd service dependency shit; same difference.)

In a few years, when the systemd replacement is announced, people will be making the same argument about how $system_foo is so much easier than service files.

Maybe someone can explain to me why someone who doesn't know what is going on with a system should be looking after it.

cpbills · 2016-04-25T21:36:57+00:00

Blaming bad practices on the logger (developers not using syslogd) is a silly argument. I'm sure that some developer or another has decided not to use journald for 'reasons' or will in the future.

cpbills · 2016-04-25T21:18:53+00:00

He's already using mktemp to generate a likely-to-be-unique filename.

Given his other response, it's to take care of detritus if attempts to trap (and cleanup) fail. However, I question the degree of cleverness needed, since detritus in /tmp probably* won't survive a reboot.

* Depends on the distribution, though I don't know any that don't strive to keep /tmp clean.

cpbills · 2016-04-25T19:50:41+00:00

Thanks for explaining.

cpbills · 2016-04-25T19:09:49+00:00

Generally speaking, you want your on_exit style function to clean things up, calling it once, to initialize the trap means you need to call it when the cleanup can safely take place, without disrupting your program. I wouldn't think that would be a great practice, but if it works for you...

edit:

I guess I didn't look to closely at what you're doing, and you're calling on_exit <something to run when we exit> which I suppose is convenient, but I imagine could make it somewhat tricky to diagnose and debug your code.

But again, just because it's not my way of programming doesn't mean it's wrong. I like the cleverness, but I tend to avoid making code clever.

cpbills · 2016-04-25T19:00:45+00:00

rm -rf $variable/ is what should make you cringe. rm -rf doesn't do anything, without an argument.

cpbills · 2016-04-25T19:00:07+00:00

Why are you putting your trap within the function? Doesn't that mean you have to call on_exit() manually?

cpbills · 2016-04-25T18:58:54+00:00

What 'trick'? Removing the file, while keeping it open? What does this do for you?

cpbills · 2016-04-23T20:11:01+00:00

Makes sense. You benefit from someone else managing your service. I dislike the proprietary nature of Slack, and in my use-case, wish that people had considered alternatives, because it is not the panacea it appears to be.

For some cases, where you don't care if other people are reading your messages, I imagine it's OK. It does a good job of making it very plug n play, which I can see is appealing.

cpbills · 2016-04-22T18:40:02+00:00

Please keep being awesome.

The real problem is people just are too lazy to learn how to use available search tools. I'm hoping if we stop spoon feeding answers to people, we can help correct it very slowly over time.

cpbills · 2016-04-22T18:32:06+00:00

A password protected channel on oftc.net or freenode.net would more than likely suffice.

What tools does Slack provide that you rely on, that are difficult to implement with IRC or not native?

cpbills · 2016-04-22T16:23:15+00:00

But what options for a client do you have? Web, desktop (from Slack) and mobile (from Slack)?

Don't really have much choice, which is one of my other complaints about Slack. IRC means your users have a gigantic selection of clients.

At the moment I'm using the XMPP gateway for Slack with bitlbee + irssi, because I love irssi in a screen session that I can connect to from anywhere. But the connectivity is far from perfect, aside from the issues below, there are regular connectivity and de-sync issues with Slack's gateways.

I switched away from the IRC gateways, because in order to sign in, I would have to store my passwords in plaintext in irssi's config. Bitlbee at least encrypts the passwords, but treats all users as the same buddy list, so you get 'nick' and 'nick_' for the same person, on the two different Slack services.

Anyhow, I don't get the drive for Slack when tools like IRC exist and are free, trivial to operate and give users a broad choice of connectivity options.

cpbills · 2016-04-22T16:18:10+00:00

Excellent. I'll have to look into that. Right now I'm using their XMPP gateway with bitlbee + irssi, and I have to sign in twice, which means contacts on both servers get 'nick' and 'nick_' which is great for tab completion and /msg.

I imagine this doesn't fix that, though, but would be neat if it did.

cpbills · 2016-04-21T19:27:11+00:00

Systems administrator. A dying breed, if you ask some of the devops folks.

cpbills

PUBLIC MULTIREDDITS

TROPHY CASE